NMP PHD

Universidade Nova de Lisboa
Faculdade de Cincias e Tecnologia

Departamento de Informtica
GESTO DE DADOS PARTILHADOS EM
AMBIENTES DE COMPUTAO MVEL
NUNO MANUEL RIBEIRO PREGUIA
Dissertao apresentada para a obteno do Grau de
Doutor em Informtica pela Universidade Nova de
Lisboa, Faculdade de Cincias e Tecnologia.
Lisboa
2003
ii
Orientador: Professor Jos Legatheaux Martins, Professor Associado do Departamento de Informtica
da Faculdade de Cincias e Tecnologia da Universidade Nova de Lisboa.
Agradecimentos
Para a realizao deste trabalho contriburam, directa ou indirectamente, diversas pessoas a que eu desejo
agradecer.
Em particular, quero agradecer ao meu orientador, Jos Legatheaux Martins, pelo constante apoio,
disponibilidade e conselhos dados. A liberdade que me concedeu para prosseguir o meu caminho e o seu
encorajamento foram igualmente importantes na realizao deste trabalho.
Ao Henrique Joo, Srgio Duarte, Carlos Baquero, Lus Caires e Joo Seco, com os quais traba-
lhei em diversos projectos, quero agradecer pelas discusses tidas sobre tpicos relacionados com este
trabalho.
Os alunos Miguel Cunha, Ins Vicente, Paulo Albuquerque e Filipe Leito, merecem o meu agrade-
cimento pela contribuio prestada no desenvolvimento e teste dos prottipos descritos nesta dissertao.
Quero igualmente agradecer ao Marc Shapiro, pela recepo e apoio prestado durante a minha esta-
dia em Cambridge. A colaborao no projecto IceCube abriu-me novas oportunidades de investigao.
Quero igualmente agradecer aos restantes elementos do grupo de sistemas distribudos pelo apoio que
me prestaram sempre que necessrio.
Os meus pais, que sempre me incentivaram e apoiaram merecem um agradecimento especial. Elsa,
pelo incentivo e compreenso demonstrada durante este longo percurso. Aos meus amigos pelo incentivo
prestado.
Finalmente, no posso deixar de agradecer ao Lus Caires, Lus Monteiro e Jos Legatheaux Martins
pelo papel decisivo que tiveram na minha deciso de voltar faculdade.
Este trabalho, assim como as deslocaes a conferncias e reunies apenas foi possvel com o apoio
nanceiro do Departamento de Informtica, Centro de Informtica e Tecnologia da Informao e Facul-
dade de Cincias e Tecnologia da Universidade Nova de Lisboa, Fundao para a Cincia e Tecnologia
atravs dos projectos Mobisnap (PRAXIS XXI/P/EEI/12188/1998) e Databricks (33924/99 FCT/MCT),
Comisso Europeia e Fundo Social Europeu, Fundao Luso-Americana para o Desenvolvimento.
iii
iv
Sumrio
Ageneralizao da utilizao de dispositivos computacionais portteis e de sistemas de comunicao sem
os deu origem a um novo ambiente de computao distribuda que se designa por ambiente de compu-
tao mvel. Este ambiente de computao apresenta caractersticas prprias que obrigam adaptao
dos vrios elementos de um sistema informtico, entre os quais o sistema de gesto de dados.
Esta dissertao aborda os problemas relativos gesto de dados partilhados em ambientes de com-
putao mvel. Para lidar com estes problemas, prope-se, como princpio fundamental, a utilizao
generalizada da informao semntica associada aos dados e s operaes executadas pelos utilizadores.
Nesta dissertao identica-se, ainda, um conjunto de princpios gerais que, explorando a informa-
o semntica disponvel, permitem a mltiplos utilizadores partilharem informao num ambiente de
computao mvel. Estes princpios podem agrupar-se em dois grandes grupos. O primeiro grupo tem
por objectivo permitir aos utilizadores acederem e modicarem os dados que necessitam em qualquer si-
tuao de conectividade recorrendo a: replicao optimista; replicao parcial secundria; e continuao
da operao apesar das faltas na replicao invocao cega. O segundo grupo tem por objectivo lidar e
controlar as modicaes concorrentes recorrendo a: preveno de conitos; propagao das operaes
e reconciliao dependente da situao; e tratamento da informao sobre a evoluo dos dados.
Estes princpios gerais foram desenvolvidos e validados durante o desenho, implementao e teste
de dois sistemas de gesto de dados com caractersticas distintas. O sistema DOORS um repositrio
de objectos desenhado para simplicar a criao de aplicaes cooperativas assncronas. O sistema
Mobsinap um sistema de bases de dados desenhado para suportar o desenvolvimento de aplicaes
tpicas de bases de dados relacionais num ambiente de computao mvel.
Para colocar em prtica os princpios identicados, explorando a informao semntica disponvel,
foi necessrio desenvolver um conjunto de tcnicas de gesto de dados especcas para cada um dos
sistemas anteriores. Estas tcnicas so igualmente apresentadas nesta dissertao.
v
vi
Abstract
The widespread use of mobile devices and wireless communications has created a new distributed com-
puting environment, usually called mobile computing environment. Computing systems, including data
management systems, must be adapted to address the new and intrinsic characteristics of these environ-
ments.
This dissertation studies data management for mobile computing, and, in particular, the problems
involved in data sharing. To address these problems, we propose the extensive use of semantic informa-
tion.
This dissertation also identies a set of principles that explore the available semantic information to
allow multiple users to share data in a mobile computing environment. We divide these principles into
two groups. The rst group aims at providing near-permanent read and write data availability in the
presence of any connectivity conditions relying on: optimistic replication; partial caching; and opera-
tion during cache misses blind invocation. The second group deals with concurrent operation relying
on: conict avoidance; log propagation and situation-specic reconciliation; and handling of awareness
information.
These principles were developed and validated during the design, implementation and evaluation
of two data management systems for mobile computing with different characteristics. DOORS is an
object repository designed to simplify the development of new asynchronous groupware applications.
Mobisnap is a relational database system designed to support typical database applications in a mobile
computing environment.
The principles identied in this dissertation were applied, in each system, using different data ma-
nagement techniques that explore the available semantic information. These specic techniques are also
presented in this dissertation.
vii
viii
Contedo
1 Introduo 1
1.1 Motivao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 Aplicaes cooperativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.2 Outras aplicaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Sistemas distribudos de gesto de dados . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Viso geral e contribuies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1 DOORS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.2 Mobisnap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 ndice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2 Princpios gerais 9
2.1 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Motivao - algumas aplicaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Princpios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.1 Replicao optimista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.2 Reconciliao dependente da situao . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.3 Replicao baseada na propagao de operaes . . . . . . . . . . . . . . . . . 14
2.3.4 Informao sobre a evoluo dos dados e da actividade cooperativa . . . . . . . 16
2.3.5 Replicao secundria parcial . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.6 Invocao cega . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.7 Preveno de conitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.8 Suporte para os programadores . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4 Sumrio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3 Apresentao do sistema DOORS 23
3.1 Modelo geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.1 Modelo de manipulao dos coobjectos . . . . . . . . . . . . . . . . . . . . . . 25
ix
x CONTEDO
3.1.2 Modelo de funcionamento do sistema . . . . . . . . . . . . . . . . . . . . . . . 26
3.2 Framework de componentes: princpios gerais . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.1 Subobjectos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.2 Funcionamento global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3 Framework de componentes: componentes . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3.1 Atributos do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3.2 Atributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3.3 Registo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3.4 Reconciliao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3.5 Awareness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3.6 Adaptao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.3.7 Cpsula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.3.8 Gestor de subobjectos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.3.9 Subobjectos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3.10 Denio de um coobjecto: exemplo . . . . . . . . . . . . . . . . . . . . . . . 46
3.4 Framework de componentes: implementao . . . . . . . . . . . . . . . . . . . . . . . 47
3.4.1 Pr-processador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.4.2 Sumrio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4 Descrio das funcionalidades principais do sistema DOORS 51
4.1 Reconciliao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1.1 Informao de ordenao das operaes . . . . . . . . . . . . . . . . . . . . . . 52
4.1.2 Sem ordem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.1.3 Ordem causal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.1.4 Ordem total . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.1.5 Transformao de operaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.1.6 Operaes do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2 Replicao secundria parcial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.3 Invocao cega . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.3.1 Cpias de substituio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.4 Integrao de sesses sncronas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.4.1 Diferentes operaes para sesses sncronas e assncronas . . . . . . . . . . . . 64
4.4.2 Discusso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
CONTEDO xi
5 Avaliao do modelo do sistema DOORS 69
5.1 Editor multi-sncrono de documentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.1.1 Coobjecto documento estruturado . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.1.3 Invocao cega . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.1.4 Edio assncrona . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.1.5 Edio sncrona . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.2 Agenda partilhada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.2.1 Coobjecto agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.2.3 Invocao cega . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.3 Outras aplicaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6 Ncleo do sistema DOORS 81
6.1 Coobjectos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.1.1 Criao de um coobjecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.1.2 Criao de um subobjecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.1.3 Remoo de um coobjecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.1.4 Remoo de um subobjecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.1.5 Verso dos coobjectos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.1.6 Sistema de nomes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.2 Servidores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.2.1 Volumes e liao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.2.2 Sincronizao epidmica dos servidores . . . . . . . . . . . . . . . . . . . . . . 89
6.2.3 Servio de descoberta e disseminao de eventos . . . . . . . . . . . . . . . . . 91
6.2.4 Interaco com os clientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.2.5 Recursos associados aos coobjectos . . . . . . . . . . . . . . . . . . . . . . . . 94
6.2.6 Suporte para mltiplas bases de dados . . . . . . . . . . . . . . . . . . . . . . . 94
6.2.7 Servio de awareness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.3 Clientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.3.2 Detalhes do funcionamento dos coobjectos . . . . . . . . . . . . . . . . . . . . 98
6.3.3 Execuo sncrona e garantias de sesso . . . . . . . . . . . . . . . . . . . . . . 100
6.3.4 Servios bsicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.3.5 Comunicao entre clientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
xii CONTEDO
6.3.6 Servio de awareness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.4 Sumrio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
7 Apresentao do sistema Mobisnap 103
7.1 Modelo geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
7.2 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
7.2.1 Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
7.2.2 Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
7.2.3 Prottipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
7.3 Transaces mveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
7.3.1 Processamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
7.3.2 Processamento alternativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
8 Reservas 115
8.1 Tipos de reservas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
8.1.1 Reservas value-change e slot . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
8.1.2 Reserva value-lock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
8.1.3 Reservas value-use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
8.1.4 Reservas escrow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
8.1.5 Reservas shared value-change e shared slot . . . . . . . . . . . . . . . . . . . . 119
8.2 Concesso e garantia de respeito pelas reservas . . . . . . . . . . . . . . . . . . . . . . 119
8.3 Processamento das transaces mveis no cliente . . . . . . . . . . . . . . . . . . . . . 122
8.3.1 Vericao da possibilidade de garantir uma transaco mvel . . . . . . . . . . 122
8.4 Processamento das transaces mveis no servidor . . . . . . . . . . . . . . . . . . . . 125
8.5 Exemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
9 Avaliao do modelo bsico do sistema Mobisnap 131
9.1 Aplicaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
9.1.1 Suporte a uma fora de vendas . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
9.1.2 Agenda partilhada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
9.1.3 Sistema de reserva de bilhetes de comboio . . . . . . . . . . . . . . . . . . . . . 134
9.1.4 Metodologia de concepo das transaces mveis . . . . . . . . . . . . . . . . 134
9.2 Reservas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
9.2.1 Modelo das experincias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
9.2.2 Previso vel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
9.2.3 Previso no vel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
CONTEDO xiii
10 Sistema de reconciliao SqlIceCube 149
10.1 Modelo geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
10.2 Relaes estticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
10.2.1 Relaes da aplicao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
10.2.2 Relaes dos dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
10.2.3 Transaces independentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
10.3 Algoritmo de reconciliao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
10.3.1 Heurstica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
10.3.2 Algoritmo bsico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
10.3.3 Complexidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
10.4 Optimizao da reconciliao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
10.4.1 Parties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
10.4.2 Compresso de uma sequncia de transaces . . . . . . . . . . . . . . . . . . . 159
10.5 Extraco automtica de relaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
10.5.1 Extraco de informao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
10.5.2 Inferir relaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
10.5.3 Exemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
10.5.4 Extenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
10.6 Observaes nais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
11 Trabalho relacionado 173
11.1 Replicao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
11.1.1 Modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
11.1.2 Arquitecturas e tipos de rplicas . . . . . . . . . . . . . . . . . . . . . . . . . . 175
11.1.3 Unidade de replicao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
11.1.4 Replicao antecipada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
11.1.5 Invocao cega . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
11.1.6 Propagao das modicaes: propagar o qu? . . . . . . . . . . . . . . . . . . 179
11.1.7 Deteco das modicaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
11.1.8 Propagao das modicaes: propagar como? . . . . . . . . . . . . . . . . . . 181
11.1.9 Reconciliao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
11.1.10 Preveno de conitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
11.2 Informao sobre a evoluo dos dados . . . . . . . . . . . . . . . . . . . . . . . . . . 189
11.3 Integrao de sesses sncronas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
xiv CONTEDO
12 Concluses 193
12.1 Sumrio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
12.2 Trabalho futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
A DOORS 197
A.1 Filiao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
A.1.1 Coobjecto de liao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
A.1.2 Protocolo local de mudana de vista . . . . . . . . . . . . . . . . . . . . . . . . 200
A.1.3 Protocolo de entrada no grupo de replicadores de um volume . . . . . . . . . . . 201
A.1.4 Protocolo de sada voluntria do grupo de replicadores de um volume . . . . . . 202
A.1.5 Operao de disseminao e execuo . . . . . . . . . . . . . . . . . . . . . . . 204
A.1.6 Protocolo de eliminao do identicador de um servidor removido . . . . . . . . 206
A.1.7 Protocolo de sada forada do grupo de replicadores de um volume . . . . . . . 207
A.1.8 Protocolo de execuo dos blocos s-uma-vez em ordenaes por vericao da
estabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
A.2 Sincronizao epidmica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
A.2.1 Informao utilizada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
A.2.2 Protocolo de propagao epidmica bilateral . . . . . . . . . . . . . . . . . . . 213
A.2.3 Protocolo de propagao epidmica unilateral . . . . . . . . . . . . . . . . . . . 218
A.2.4 Sincronizao epidmica durante as mudanas na liao . . . . . . . . . . . . . 218
A.2.5 Disseminao de novas operaes . . . . . . . . . . . . . . . . . . . . . . . . . 220
B Mobisnap 221
B.1 Transaces mveis:linguagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Lista de Figuras
3.1 Arquitectura do sistema DOORS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Framework de componentes DOORS. . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3 Interface do coobjecto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1 Dissertao representada como um documento estruturado. . . . . . . . . . . . . . . . . 70
5.2 Organizao de um documento estruturado em subobjectos. . . . . . . . . . . . . . . . . 71
5.3 Edio de um documento LaTeX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.4 Cpias de substituio na edio de um documento estruturado. . . . . . . . . . . . . . 75
5.5 Elementos de edio sncrona no editor multi-sncrono. . . . . . . . . . . . . . . . . . . 76
5.6 Aplicao de agenda partilhado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.1 API do sistema DOORS para manipulao dos coobjectos. . . . . . . . . . . . . . . . . 82
6.2 Interface do servidor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.3 API do sistema DOORS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
7.1 Transaco mvel nova encomenda com duas alternativas . . . . . . . . . . . . . . . . . 104
7.2 Arquitectura do sistema Mobisnap. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
8.1 Transaco mvel nova encomenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
8.2 Transaco mvel reserva de bilhete . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
8.3 Transaco mvel reserva de bilhete: segunda alternativa . . . . . . . . . . . . . . . . . 129
8.4 Transaco mvel nova marcao numa agenda . . . . . . . . . . . . . . . . . . . . . . 130
9.1 Transaco mvel cancela encomenda . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
9.2 Transaco mvel remove marcao numa agenda . . . . . . . . . . . . . . . . . . . . . 133
9.3 Transaces aceites localmente (cenrio MOV:PEQ:BOM) . . . . . . . . . . . . . . . . 139
9.4 Transaces aceites localmente (cenrio MOV:GRD:BOM) . . . . . . . . . . . . . . . . 139
9.5 Transaces aceites localmente (cenrio DIS:PEQ:BOM) . . . . . . . . . . . . . . . . . 140
9.6 Transaces aceites imediatamente no cliente ou no servidor (cenrio MOV:PEQ:BOM) . 141
xv
xvi LISTA DE FIGURAS
9.7 Transaces aceites imediatamente no cliente ou no servidor (cenrio DIS:PEQ:BOM) . 141
9.8 Transaces aceites imediatamente no cliente ou no servidor (cenrio MOV:GRD:BOM) 142
9.9 Mensagens enviadas na obteno de novas reservas (cenrios MOV:PEQ:BOM e
MOV:GRD:BOM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
9.10 Transaces aceites localmente (cenrio MOV:PEQ:MAU) . . . . . . . . . . . . . . . . 143
9.11 Transaces aceites imediatamente no cliente ou no servidor localmente (cenrio
MOV:PEQ:MAU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
9.12 Transaces aceites localmente sem obteno inicial de reservas (cenrio MOV:PEQ:MAU)144
9.13 Transaces aceites localmente semobteno inicial de reservas (cenrio MOV:GRD:MAU)145
9.14 Transaces aceites imediatamente no cliente ou no servidor sem obteno inicial de
reservas (cenrio MOV:PEQ:MAU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
9.15 Mensagens enviadas na obteno de novas reservas (cenrios MOV:PEQ:MAU e
MOV:GRD:MAU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
9.16 Mensagens enviadas na obteno de novas reservas sem obteno inicial de reservas
(cenrios MOV:PEQ:MAU e MOV:GRD:MAU) . . . . . . . . . . . . . . . . . . . . . . 146
10.1 Ordenao de um conjunto de operaes executadas concorrentemente. . . . . . . . . . 150
10.2 Algoritmo de reconciliao (sem parties) . . . . . . . . . . . . . . . . . . . . . . . . 155
10.3 Algoritmo de criao de uma nica soluo. . . . . . . . . . . . . . . . . . . . . . . . . 156
10.4 Algoritmo de reconciliao (com parties). . . . . . . . . . . . . . . . . . . . . . . . . 157
10.5 Informao extrada de uma transaco mvel nova encomenda . . . . . . . . . . . . . . 163
10.6 Informao extrada da transaco mvel cancela encomenda (sem indireces) . . . . . 166
10.7 Informao extrada da transaco mvel nova marcao simples . . . . . . . . . . . . . 167
10.8 Informao extrada da transaco mvel cancela marcao usando os detalhes da mar-
cao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
10.9 Diviso de uma transaco composta por uma sequncia de instrues if . . . . . . . . . 171
10.10Diviso de uma transaco composta por uma conjunto de instrues if encadeadas . . . 172
A.1 Funes bsicas e informao usada no protocolo de sincronizao bilateral (simplicado).215
A.2 Funes do protocolo de sincronizao bilateral (simplicado). . . . . . . . . . . . . . . 216
A.3 Descrio da sincronizao de um coobjecto usando o protocolo de sincronizao bilateral.217
A.4 Funes do protocolo de sincronizao unilateral (simplicado). . . . . . . . . . . . . . 219
Lista de Tabelas
8.1 Tabela de compatibilidade das reservas. . . . . . . . . . . . . . . . . . . . . . . . . . . 120
8.2 Reservas obtidas para garantir encomendas . . . . . . . . . . . . . . . . . . . . . . . . 127
8.3 Reservas obtidas para garantir reservas de bilhetes . . . . . . . . . . . . . . . . . . . . . 128
8.4 Reservas obtidas para garantir reservas de bilhetes: segunda alternativa . . . . . . . . . . 128
8.5 Reservas obtidas para garantir novas marcaes numa agenda . . . . . . . . . . . . . . . 129
9.1 Parmetros das experincias: durao e falhas. . . . . . . . . . . . . . . . . . . . . . . . 136
9.2 Parmetros das experincias: congurao do sistema simulado. . . . . . . . . . . . . . 136
9.3 Parmetros das experincias: exactido das previses. . . . . . . . . . . . . . . . . . . . 136
xvii
xviii LISTA DE TABELAS
Captulo 1
Introduo
Os avanos tecnolgicos produzidos na ltima dcada permitiram a generalizao da utilizao de com-
putadores portteis e de comunicaes sem os. expectvel que esta tendncia se mantenha e acentue
nos prximos anos, com um incremento do nmero e capacidade dos dispositivos mveis, uma melhoria
das comunicaes sem os e a generalizao da integrao destes dois elementos. Em resultado da fu-
so destes desenvolvimentos tecnolgicos e da viabilidade econmica da sua generalizao, criou-se um
novo ambiente de computao, a que se chama genericamente (ambiente de) computao mvel.
A computao mvel apresenta caractersticas intrnsecas distintas das caractersticas dos sistemas
distribudos tradicionais [149, 7, 124]. Entre estas, podem destacar-se as restries de disponibilidade
energtica, a conectividade de qualidade varivel e os reduzidos recursos de hardware de, pelo menos,
uma parte signicativa dos dispositivos mveis (quando comparados com os computadores de secret-
ria). Assim, os sistemas informticos desenhados para estes ambientes tm de tomar em considerao
e adaptar-se a essas caractersticas. Nesta dissertao aborda-se o problema da gesto de dados em
ambientes de computao mvel.
A computao mvel apresenta, alm das diferenas de hardware e conectividade, uma caracters-
tica adicional potencialmente distintiva: os utilizadores tm acesso (quase) permanente aos dispositivos
mveis. Ao nvel da gesto de dados, esta caracterstica sugere a necessidade de uma disponibilidade
permanente dos dados e potencia o acesso concorrente a dados partilhados.
Esta dissertao apresenta solues de gesto de dados partilhados para ambientes de computao
mvel que tomam em considerao as caractersticas especiais deste novo tipo de ambiente de computa-
o.
Este captulo estabelece o contexto desta dissertao. Primeiro, apresenta-se um conjunto de aplica-
es para ambientes de computao mvel em que a partilha de dados uma necessidade. De seguida,
discutem-se as limitaes das solues tradicionais no suporte s aplicaes anteriores. Finalmente,
apresentam-se brevemente as solues propostas nesta dissertao, realando as suas contribuies.
1
2 CAPTULO 1. INTRODUO
1.1 Motivao
Um sistema distribudo de gesto de dados armazena informao que pode ser acedida a partir de dife-
rentes computadores interligados por uma rede de comunicaes. Esta informao, ou, pelo menos, uma
parte desta informao acedida e modicada por mais do que um utilizador. De seguida apresentam-se
alguns exemplos desta situao.
1.1.1 Aplicaes cooperativas
Numa actividade cooperativa, um conjunto de utilizadores actua em conjunto para alcanar um objectivo
comum. Nas aplicaes de suporte s actividade cooperativas (geralmente designadas por groupware), o
estado da actividade cooperativa geralmente mantida sob a forma de dados partilhados. Os utilizadores
produzem as suas contribuies para a actividade cooperativa modicando os dados partilhados.
Nas aplicaes de trabalho em grupo assncrono, os utilizadores produzem as suas modicaes
em diferentes momentos ou sem conhecimento imediato das modicaes produzidas pelos outros uti-
lizadores. Assim, estas aplicaes apresentam um cenrio paradigmtico da necessidade de mltiplos
utilizadores acederem e modicarem dados partilhados.
As seguintes aplicaes so exemplos tpicos de aplicaes de suporte ao trabalho cooperativo as-
sncrono [11, 47, 144]. Num sistema de conferncia assncrono, mltiplos utilizadores cooperam na
discusso de vrios assuntos usando um espao de mensagens partilhado. Num editor cooperativo de do-
cumento, vrios utilizadores cooperam na criao de um documento. Numa agenda partilhada, mltiplos
utilizadores coordenam as suas marcaes.
1.1.2 Outras aplicaes
A necessidade de mltiplos utilizadores acederem a dados partilhados no uma caracterstica apenas
das aplicaes de trabalho em grupo. Muitas outras aplicaes e servios apresentam este requisito.
Por exemplo, numa aplicao de suporte a uma fora de vendas mvel, os vendedores necessitam
de aceder e modicar a informao sobre os clientes e sobre os produtos disponibilizados pela empresa,
para alm das encomendas realizadas. No servio de reservas de lugares de avio, mltiplos clientes
necessitam de aceder informao sobre os lugares disponveis e introduzir e cancelar reservas.
1.2 Sistemas distribudos de gesto de dados
As aplicaes descritas anteriormente exemplicam a necessidade de aceder e modicar dados partilha-
dos. Para que os utilizadores possam executar as suas aces, o sistema de gesto de dados deve fornecer
uma elevada disponibilidade de servio, permitindo, idealmente, que qualquer utilizador aceda aos dados
1.2. SISTEMAS DISTRIBUDOS DE GESTO DE DADOS 3
partilhados para leitura e escrita em qualquer momento. Num sistema distribudo, e, em particular, num
ambiente de computao mvel, impossvel garantir o acesso permanente aos dados a partir de um
nico servidor [30] devido s falhas nas comunicaes e nos servidores. Assim, o sistema necessita de
recorrer replicao dos dados para fornecer uma elevada disponibilidade.
Num sistema distribudo de grande-escala, que inclua computadores interligados por redes de longa-
distncia (WAN), pode ser impossvel coordenar os acessos executados por mltiplos utilizadores devido
impossibilidade de contactar alguns computadores. Num ambiente de computao mvel, esta impos-
sibilidade reforada pelas seguintes caractersticas. Primeiro, a inexistncia ou reduzida qualidade da
conectividade em algumas zonas e perodos de tempo. Segundo, a necessidade de economizar energia
pode levar desconexo dos dispositivos mveis ou dos subsistemas de comunicao. Terceiro, razes
econmicas podem condicionar a conectividade em alguns perodos de tempo.
A coordenao de mltiplos utilizadores, mesmo quando possvel, pode ser indesejvel devido
elevada latncia induzida por essa coordenao ou devido s caractersticas da aplicao. Assim, os
esquemas de replicao tradicionais [17], que coordenam os acessos de mltiplos utilizadores, so ina-
propriados, porque incorrem numa elevada latncia e/ou reduzida disponibilidade [30]. Os sistemas de
gesto de dados para ambientes mveis devem, alternativamente, recorrer a um modelo de replicao
optimista, que lhes permita fornecer uma elevada disponibilidade de leitura e escrita.
Num sistema de gesto de dados baseado em replicao optimista, permite-se que cada utilizador
modique uma cpia dos dados sem coordenao prvia. Como vrios utilizadores podem modicar
concorrentemente os dados, levando divergncia das vrias rplicas, necessrio que o sistema de
gesto de dados inclua um mecanismo de reconciliao de rplicas que permita lidar com a situao.
Este mecanismo de reconciliao deve, em geral, garantir a convergncia nal dos dados, i.e., deve
garantir que aps todas as modicaes serem reectidas em todas as rplicas, o estado de todas as
rplicas idntico. Outra propriedade a satisfazer a preservao das intenes dos utilizadores, i.e., o
efeito de uma modicao deve reectir a inteno do utilizador quando este a executou.
Vrias solues de reconciliao foram propostas e utilizadas em sistemas de gesto de dados [147,
124]. Em geral, a utilizao de informao semntica associada aos dados e s operaes produzidas
para modicar os dados a chave para o desenvolvimento de uma boa soluo. No entanto, nenhuma
soluo proposta parece ser ideal em todas as situaes. Assim, a reconciliao continua a ser uma rea
problemtica no desenvolvimento de um sistema de gesto de dados baseado em replicao optimista.
Muitos sistemas de gesto de dados baseados em replicao optimista permitem a denio de so-
lues especcas de reconciliao (baseadas numa dada estratgia adoptada). No entanto, apesar de
em alguns casos ser possvel reutilizar a mesma aproximao em problemas diferentes (com pequenas
adaptaes), no existe geralmente suporte para a reutilizao de solues pr-denidas. Assim, pa-
rece desejvel a existncia de um repositrio de solues pr-denidas que possam ser utilizadas em
diferentes situaes, de forma a simplicar o desenvolvimento de novas solues de gesto de dados.
A necessidade de reconciliar as modicaes produzidas concorrentemente por vrios utilizadores
leva impossibilidade de garantir o resultado ou efeito nal de uma modicao aquando da sua execu-
o pelo utilizador. Apenas aps o processo de reconciliao, o resultado e efeito nal da modicao
determinado. No entanto, em algumas aplicaes, o conhecimento imediato do resultado de uma ope-
rao desejvel ou mesmo imprescindvel. As solues propostas anteriormente para lidar com este
problema [111, 168] apresentam algumas limitaes, entre as quais se destaca a aplicabilidade a apenas
um limitado conjunto de tipos de dados. Adicionalmente, a no integrao com um modelo de reconci-
liao genrico impede a denio de um modelo global de gesto de dados replicados.
Nas actividades cooperativas, o conhecimento do modo como os dados partilhados evoluem foi iden-
ticado como importante para o sucesso das contribuies produzidas [43, 65, 99]. No entanto, os sis-
temas de gesto de dados tendem a ignorar este problema, levando as aplicaes a desenvolver solues
prprias e sem suporte adequado do sistema. Um caso particular deste problema o conhecimento do
resultado nal das operaes produzidas pelo prprio utilizador note-se que o processo de reconcili-
ao pode terminar num momento em que o utilizador j no est a utilizar a aplicao/sistema. Apesar
do modo como esta informao produzida, tratada e transmitida aos utilizadores dever depender da
aplicao ou situao, desejvel que o sistema integre suporte para o seu tratamento.
Outra limitao comum nos sistemas distribudos de gesto de dados prende-se com o tratamento de
situaes de faltas na replicao. Em geral, qualquer acesso a um objecto do qual no se possui um cpia
local impossibilitado. No entanto, em algumas situaes, um utilizador pode produzir contribuies
positivas nestas situaes. Por exemplo, possvel requisitar a marcao de uma reunio numa agenda
apesar de ser impossvel aceder ao seu contedo. Desta forma, o sistema de gesto de dados deve incluir
suporte para lidar com estas situaes.
1.3 Viso geral e contribuies
Esta dissertao apresenta um conjunto de contribuies sobre mtodos e estratgias para lidar com o
problema da gesto de dados partilhados em ambientes de computao mvel e formula um conjunto de
princpios gerais desenvolvidos e validados durante o desenho, implementao e teste de dois sistema
de gesto de dados. O DOORS um repositrio de objectos desenhado com o objectivo de suportar a
criao de aplicaes cooperativas assncronas. O Mobsinap um sistema de bases de dados desenhado
para suportar o desenvolvimento de aplicaes tpicas de bases de dados relacionais num ambiente de
computao mvel.
Apesar das diferenas entre os dois sistemas, eles so construdos com base num conjunto de prin-
1.3. VISO GERAL E CONTRIBUIES 5
cpios comuns usados para lidar com as caractersticas dos ambientes de computao mvel. Entre os
princpios identicados, podem destacar-se os seguintes:
A utilizao de um modelo de replicao optimista para aumentar a disponibilidade de leitura e
escrita dos dados. Estendendo o modelo tradicional de replicao optimista, permite-se que, em
algumas situaes, os utilizadores submetam operaes sobre dados no replicados localmente.
A replicao parcial dos dados nos clientes como forma de lidar com os limitados recursos dispo-
nveis (em termos de armazenamento local e de comunicaes) em alguns clientes mveis.
A utilizao de tcnicas de reconciliao que exploram a informao semntica disponvel na
resoluo de conitos. A propagao das modicaes como sequncias de operaes, permitindo
maximizar a informao semntica disponvel.
A utilizao de tcnicas de preveno de conitos para obter, de forma independente, o resultado
nal das operaes submetidas em clientes mveis (e desconectados).
A integrao de mecanismos para tratamento da informao sobre a evoluo dos dados partilha-
dos de forma a fornecer, aos utilizadores, informao sobre as modicaes executadas concor-
rentemente e sobre o resultado ou efeito nal das suas prprias modicaes. Como se referiu
anteriormente, este aspecto geralmente negligenciado nos sistema de gesto de dados.
Estes princpios, assim como as tcnicas propostas para os colocar em prtica, adoptam como apro-
ximao elementar a utilizao da informao semntica disponvel para criar solues adaptadas s
caractersticas do ambiente de computao mvel e das aplicaes que se pretende desenvolver. De se-
guida, resumem-se as caractersticas de cada sistema, destacando as contribuies desta dissertao em
cada uma das aproximaes.
1.3.1 DOORS
O sistema DOORS um repositrio de objectos baseado numa arquitectura cliente estendido/servidor
replicado. O sistema gere objectos estruturados de acordo com o framework
1
de componentes DOORS,
a que se chamam coobjectos. Os coobjectos so entidades de granularidade elevada que representam
tipos de dados complexos por exemplo, um documento estruturado ou uma agenda. Um coobjecto
pode ser decomposto num conjunto de elementos individuais, os subobjectos, cada um composto por um
1
Em contextos semelhantes, o termo framework tem sido traduzido, entre outros, por modelo ou organizao. No entanto,
por se considerar que a utilizao destas tradues no incluem o sentido completo dado utilizao do termo original, que
inclui no apenas a denio do conjunto de componentes usados mas tambm o modo como se organizam e actuam conjunta-
mente para implementar uma dada funcionalidade, decidiu-se utilizar o termo ingls em itlico.
grafo de objectos elementares por exemplo, um documento estruturado composto por um conjunto
de seces. Os coobjectos so agrupados em conjuntos de coobjectos relacionados (representando um
espao de trabalho partilhado ou os dados de uma actividade cooperativa).
Para fornecer uma elevada disponibilidade combinam-se as seguintes tcnicas. Os servidores repli-
cam conjuntos completos de coobjectos para mascarar falhas nos servidores e no sistema de comunica-
es. Os clientes mantm cpias parciais de um subconjunto de coobjectos para permitir o funciona-
mento durante os perodos de desconexo. O acesso aos dados baseado numa aproximao optimista
em que qualquer cliente pode modicar os coobjectos: as modicaes so propagadas sob a forma de
operaes (invocao de mtodos denidos na interface dos subobjectos).
O ncleo do sistema apenas inclui os servios mnimos de gesto de dados, delegando nos coobjectos
o tratamento dos aspectos especcos relacionados com a partilha dos dados. Para tratar destes proble-
mas, o framework de componentes DOORS decompe o funcionamento de um coobjecto em vrios
componentes, cada um lidando com um aspecto relacionados com a partilha dos dados. Os principais
aspectos considerados so a reconciliao de modicaes concorrentes e o tratamento da informao
sobre a evoluo dos dados. Esta aproximao permite utilizar, em diferentes coobjectos, diferentes es-
tratgias de resoluo dos vrios problemas e no apenas adaptar uma nica estratgia (como usual nos
sistemas de gesto de dados). Por exemplo, relativamente reconciliao, possvel usar uma estratgia
simples baseada na ordenao total das operaes, ou solues mais complexas, como a utilizao da
transformao de operaes [46]. Esta aproximao permite, ainda, reutilizar as solues denidas, em
mltiplos coobjectos, assim simplicando a tarefa dos programadores. A denio do framework de
componentes com as propriedades descritas uma das contribuies principais do sistema DOORS.
O sistema DOORS inclui um mecanismo de invocao cega que permite a continuao da opera-
o na presena de faltas na replicao. Alm de permitir s aplicaes submeterem operaes sobre
subobjectos dos quais no se dispe de uma cpia local, permite, ainda, vericar o resultado provisrio
da sua execuo atravs da criao de cpias de substituio. Este mecanismo outra das contribui-
es originais do sistema DOORS, permitindo minorar os problemas decorrentes das faltas na replicao
secundria.
O sistema DOORS prope tambm um modelo de integrao de sesses de trabalho cooperativo
sncrono de curta durao, no mbito de sesses assncronas de longa durao. Este modelo pode ser
decomposto em duas partes. Primeiro, dene-se um mecanismo, integrado no framework de componen-
tes, que permite manter um conjunto de cpias de um coobjecto sincronamente sincronizadas. Segundo,
prope-se a converso das operaes sncronas em assncronas para permitir a utilizao de diferentes
operaes nos dois modos de interaco (quando necessrio). Esta converso pode ser efectuada inter-
namente pelo coobjecto ou externamente pela aplicao. Esta aproximao permite que se utilizem as
1.3. VISO GERAL E CONTRIBUIES 7
tcnicas mais adequadas em cada modo de interaco, incluindo a utilizao de operaes com diferen-
tes granularidades, diferentes tcnicas de reconciliao e tratamento da informao sobre a evoluo dos
dados. O sistema DOORS o primeiro que apresenta uma soluo de integrao das sesses sncronas e
assncronas com estas caractersticas.
1.3.2 Mobisnap
O Mobisnap um sistema de bases de dados relacionais baseado numa arquitectura cliente/servidor. O
servidor nico mantm o estado ocial da base de dados. Os clientes replicam cpias parciais da base de
dados para suportar a operao durante os perodos de desconexo.
As aplicaes, que executam nos clientes, modicam o estado da base de dados submetendo peque-
nos programas escritos em PL/SQL [112], a que se chamam transaces mveis. Durante a operao
desconectada, as transaces mveis so executadas provisoriamente no cliente. Mais tarde, as transac-
es so propagadas para o servidor onde o seu resultado nal determinado reexecutando o programa
da transaco mvel. Ao contrrio da execuo e validao de transaces baseada nos conjuntos de lei-
tura e escrita, a execuo do programa das transaces mveis no servidor permite a denio de regras
de deteco e resoluo de conitos que exploram a semntica das operaes.
Para permitir determinar o resultado de uma transaco no cliente de forma independente (por exem-
plo, durante os perodos de desconexo), o sistema Mobisnap inclui um mecanismo de reservas. Uma
reserva fornece, dependendo do seu tipo, uma promessa temporria em relao ao estado da base de
dados. Um cliente pode obter um conjunto de reservas antes de se desconectar. Quando uma aplicao
submete uma transaco mvel, o sistema verica, de forma transparente, se as reservas que o cliente
possui so sucientes para garantir o seu resultado nal. Se o cliente possuir reservas sucientes, o re-
sultado local pode ser considerado nal porque as reservas garantem a inexistncia de conitos aquando
da execuo da transaco mvel no servidor.
O mecanismo de reservas do sistema Mobisnap apresenta as seguintes contribuies. Primeiro, inclui
vrios tipos de reservas (ao contrrio de propostas anteriores que apenas denem um nico tipo [111]).
Como se mostra nesta dissertao, esta caracterstica fundamental para garantir o resultado de muitas
transaces mveis. Segundo, o sistema verica de forma transparente a possibilidade de usar as reser-
vas disponveis para garantir o resultado de uma transaco mvel. Assim, no necessrio usar funes
especiais para manipular os elementos de dados reservados e qualquer transaco pode explorar todas
as reservas disponveis (e no apenas as que a transaco conhece). Terceiro, o sistema combina a im-
plementao do mecanismo de reservas com o modelo de execuo das transaces mveis num sistema
baseado em SQL.
O sistema Mobisnap inclui tambm um novo sistema de reconciliao de transaces mveis, o sis-
tema SqlIceCube. Este sistema procura maximizar o conjunto de transaces que podem ser executadas
com sucesso, usando para tal um conjunto de relaes semnticas denidas entre cada par de transaces.
Osistema SqlIceCube estende a aproximao proposta no sistema IceCube [85] e aplica-a no mbito dum
sistema de bases de dados relacionais. Alm das adaptaes necessrias, que incluem a denio de um
novo conjunto de relaes para exprimir a semntica das operaes de uma aplicao em problemas de
reconciliao, o sistema SqlIceCube inclui uma contribuio original signicativa: a extraco autom-
tica das relaes semnticas a partir do cdigo das transaces mveis. O SqlIceCube o primeiro a
utilizar a anlise esttica das operaes para extrair automaticamente a informao semntica necessria
para o sistema de reconciliao.
O sistema Mobisnap, ao ser implementado como uma camada de sistema intermdia (middleware),
representa uma aproximao evolutiva em relao mobilidade (em vez de uma aproximao revolu-
cionria). Os novos mecanismos transaces mveis, reservas e reconciliao de um conjunto de
transaces podem ser usados pelos clientes que executam no sistema Mobisnap. No entanto, os cli-
entes legados podem continuar a aceder ao servidor de bases de dados directamente, sem modicaes.
1.4 ndice
O resto desta dissertao est organizada da seguinte forma. No captulo 2 discutem-se os princpios
gerais adoptados nas solues de gesto de dados apresentadas nesta dissertao.
Nos captulos seguintes apresenta-se de forma detalhada o sistema DOORS. O captulo 3 apresenta o
modelo geral de funcionamento do sistema e o framework de componentes DOORS. O captulo 4 discute
as caractersticas fundamentais do sistema DOORS, incluindo a reconciliao, replicao secundria
parcial, invocao cega e integrao de actividades sncronas e assncronas. O captulo 5 apresentae
uma avaliao qualitativa do modelo do sistema com base num conjunto de aplicaes implementadas.
O captulo 6 detalha a arquitectura do sistema e descreve o prottipo implementado para vericar a
exequibilidade do modelo proposto.
Nos captulos seguintes detalha-se o sistema Mobisnap. O captulo 7 descreve o modelo geral de
funcionamento do sistema, incluindo o funcionamento bsico das transaces mveis. O captulo 8 de-
talha o mecanismo de reservas, incluindo a sua interaco com o processamento das transaces mveis.
O captulo 9 apresenta uma avaliao qualitativa dos mecanismos bsicos do sistema, com base num
conjunto de aplicaes. Apresenta igualmente uma avaliao quantitativa do mecanismo de reservas no
mbito de uma aplicao de suporte a uma fora de vendas mvel. O captulo 10 descreve o sistema
genrico de reconciliao para transaces mveis usado no sistema Mobisnap: o sistema SqlIceCube.
No captulo 11 discute-se o trabalho relacionado e no captulo 12 apresentam-se as concluses e
indicam-se algumas direces para trabalho futuro.
Captulo 2
Princpios gerais
No captulo anterior apresentaram-se algumas das possveis motivaes para aceder a dados partilhados
em situaes de desconexo. Neste captulo discutem-se os requisitos necessrios para permitir esse
acesso e os princpios fundamentais adoptados para responder a esses requisitos. Estes princpios cons-
tituem a base das solues apresentadas nesta dissertao. A forma como estes princpios so adaptados
s caractersticas especcas detalhada nos captulos seguintes.
2.1 Introduo
As solues apresentadas nesta dissertao assumem a existncia dum sistema informtico com as se-
guintes propriedades. O sistema composto por um conjunto de computadores heterogneos com carac-
tersticas prprias (processador, memria, dispositivos de comunicao, etc). Os computadores conse-
guem comunicar entre si atravs da troca de mensagens transmitidas atravs de uma rede de comunicao
de dados.
Assume-se que a rede de comunicao de dados tem caractersticas semelhantes Internet. Assim,
impossvel determinar o tempo de propagao de uma mensagem entre dois computadores, t
p
, mas
este valor inferior a uma dada constante caso a mensagem seja recebida no destino
1
(i.e., t
p
]0, t
p
max
]
para uma mensagem entregue e t
p
= para uma mensagem no entregue). Desta forma, as mensagens
enviadas entre dois computadores podem no chegar ao destino, ou, quando chegam, podem chegar fora
de ordem e podem-se duplicar.
Diz-se que um computador i est desconectado em relao a outro computador j quando i no con-
segue enviar mensagens para j, ou seja, o tempo de propagao de todas as mensagens enviadas de i para
1
Estas caractersticas so semelhantes s de um sistema assncrono [102], com a diferena que existe um limite superior
para o tempo de propagao duma mensagem assncrona. Esta propriedade pode ser obtida facilmente a partir dum sistema
assncrono se os relgios dos computadores estiverem, pelo menos, fracamente sincronizados: basta ignorar todas as mensagens
cujo tempo de propagao seja superior ao tempo mximo de propagao considerado
9
10 CAPTULO 2. PRINCPIOS GERAIS
j t
p
= . Diz-se simplesmente que est desconectado quando est desconectado em relao a todos os
outros computadores do sistema. A desconexo de um computador pode ser voluntria (desconexo dos
dispositivos de comunicao) ou causada por uma falha (falha na rede).
O sistema fornece um servio de gesto de dados. O servio de gesto de dados fornece dois tipos de
operao: leitura e escrita. Uma operao de leitura permite obter o valor actual dos dados. Diz-se que
os dados foram lidos quando foi executada uma operao de leitura. Uma operao de escrita permite
modicar o valor dos dados. Diz-se que os dados foram escritos ou modicados quando foi executada
uma operao de escrita. Diz-se, genericamente, que os dados foram acedidos quando foi executada uma
operao de leitura ou escrita.
Os utilizadores usam este servio (atravs das aplicaes que utilizam) para armazenar a informao
que necessitam para as suas actividades. Diz-se que um utilizador submeteu ou executou uma operao
de leitura (escrita), quando a aplicao que utiliza invoca uma operao de leitura (escrita) no sistema de
gesto de dados.
A informao armazenada no sistema de gesto de dados est organizada de acordo com o modelo
de dados suportado pelo sistema. No entanto, independentemente do modelo de dados utilizado, pode
identicar-se que a informao composta por um conjunto de unidades de informao indivisveis
para o sistema (do ponto de vista da manipulao dos dados). A estas unidades indivisveis chamam-se
genericamente objectos ou elementos de dados. Por exemplo, para dados organizados segundo o modelo
relacional, o valor de uma coluna de uma linha (registo) de uma tabela uma unidade indivisvel que se
denomina por objecto ou elemento de dados.
O sistema de gesto de dados pode manter vrias cpias dos dados. A cada uma das cpias d-se
o nome de rplica. De forma informal, dene-se a consistncia entre duas rplicas como o nmero
de modicaes que as rplicas sofreram desde a ltima vez que foram sincronizadas. Duas rplicas
so fortemente consistentes quando o nmero de modicaes desde a ltima sincronizao tende a
ser nulo, i.e., o algoritmo de gesto das rplicas procura que todas as rplicas mantenham sempre o
mesmo valor. Duas rplicas so fracamente consistentes quando o nmero de modicaes desde a
ltima sincronizao tende a ser no nulo.
No resto deste captulo discutem-se as propriedades fundamentais que um servio de gesto de dados
para permitir o acesso aos dados independentemente da conectividade existente.
2.2 Motivao - algumas aplicaes
Nesta seco vamos descrever brevemente algumas aplicaes que servem de motivao para os princ-
pios enunciados neste captulo.
2.2. MOTIVAO - ALGUMAS APLICAES 11
Num sistema de conferncia assncrono
2
existe um espao de mensagens partilhado entre vrios uti-
lizadores (semelhante ao servio de news da Internet). Estas mensagens esto organizadas em temas de
discusso. Um utilizador pode inserir uma mensagem como resposta ou adenda a outra mensagem ou
iniciar um novo tema de discusso. Um sistema deste tipo pode funcionar mantendo vrias cpias do es-
pao de mensagens partilhado. Os utilizadores devem poder ler as mensagens conhecidas na rplica que
esto a aceder e inserir novas mensagens. Apesar de no ser necessrio que todas as rplicas apresentem
o mesmo estado, conveniente que as mensagens sejam apresentadas de forma coerente, respeitando,
pelo menos, as dependncias entre mensagens (i.e., uma resposta a uma mensagem no deve aparecer
antes da mensagem original).
Uma agenda partilhada permite coordenar as marcaes executadas por mltiplos utilizadores. Exis-
tem vrios cenrios em que uma agenda partilhada pode ser til, entre os quais: uma agenda pessoal
actualizada por mais do que uma pessoa (por exemplo, o prprio e um secretrio); uma agenda para
um recurso partilhado (por exemplo, uma sala de reunio). Numa agenda partilhada, mltiplos utiliza-
dores podem inserir novas marcaes e remover marcaes existentes (sendo estas operaes sujeitas,
obviamente, a restries de controlo de acessos). De preferncia, os utilizadores devem ser autorizados
a modicar a agenda de forma independente. Estas novas marcaes devem ser consideradas provis-
rias [161] at poderem ser conrmadas atravs de alguma forma automtica de consenso global. Quando
o solicitem, os utilizadores devem receber a conrmao das suas marcaes.
Um editor cooperativo assncrono permite a um grupo de utilizadores editar conjuntamente um do-
cumento (por exemplo, um artigo). Os vrios utilizadores podem modicar o documento independente-
mente
3
(por exemplo, dois utilizadores podem modicar diferentes seces). As modicaes concor-
rentes devem ser unicadas tendo em considerao todas as modicaes produzidas (por exemplo, o
documento nal deve incluir as novas verses das vrias seces). Um aspecto importante a considerar
que a consistncia sintctica [42] deve ser mantida mesmo quando se consideram conitos semnticos,
i.e., o servio de gesto de dados deve manter os dados estruturalmente consistentes de forma a permitir
que a actividade dos utilizadores continue (por exemplo, se dois utilizadores modicam a mesma seco,
duas verses dessa seco devem ser criadas e mantidas).
Um sistema de reserva de lugares para comboios mantm informao sobre um conjunto de com-
boios e respectiva reserva de lugares. Os utilizadores podem consultar as alternativas existentes e inserir
uma nova reserva ou remover uma reserva existente. As operaes de consulta devem estar disponveis
2
Assncrono aqui tomado no sentido informal, em que o tempo que medeia entre a emisso e a recepo das mensagens
pode ser signicativo, na ordem dos minutos, horas ou mesmo dias.
3
Para que um trabalho cooperativo seja bem sucedido deve existir alguma coordenao entre os elementos do grupo (neste
exemplo, cada utilizador deve saber que seces deve modicar). O problema da coordenao entre os elementos dum grupo
cooperativo est fora do mbito desta dissertao mas foi abordado no mbito do projecto DAgora [40, 39].
sempre, ainda que alguns dados (por exemplo, o nmero de lugares disponveis) possam estar desactuali-
zados. Relativamente s operaes de insero e remoo de reservas conveniente obter imediatamente
o seu resultado nal. Para tal, pode, por exemplo, executar-se a operao na rplica ocial dos dados.
Quando no possvel obter o resultado de imediato, deve ser possvel pedir ao sistema para processar
a operao de forma diferida neste caso, o utilizador deve ser noticado do resultado do seu pedido
quando ele denitivamente executado.
Um sistema de suporte a uma fora de vendas mvel mantm informao sobre os produtos dispo-
nveis para venda. As operaes disponibilizadas e as caractersticas de funcionamento esperadas so
muito semelhantes s do sistema de reserva de lugares. No entanto, existe uma diferena que deve ser
tida em considerao. Enquanto no sistema de reserva de lugares, cada lugar pode ser identicado uni-
vocamente, num sistema de venda de bens fungveis (por exemplo, CDs), todos os elementos do mesmo
tipo so indistinguveis.
2.3 Princpios
No decurso do trabalho que conduziu a esta dissertao, identicaram-se alguns princpios que permitem
criar boas solues de gesto de dados para ambientes de computao mvel. Estes princpios, discutidos
nesta seco, foram utilizados na criao das solues apresentadas nesta dissertao.
Um princpio geral explorado nas solues apresentadas nesta dissertao consiste na utilizao da
informao semntica associada aos dados e s operaes executadas pelos utilizadores. Este princpio
geral transversal a todos os princpios identicados e permite criar solues especialmente adaptadas a
cada problema, como se discute na apresentao dos vrios princpios.
2.3.1 Replicao optimista
Num sistema distribudo impossvel garantir a permanente acessibilidade armazenando os dados ape-
nas num computador [30]. Esta impossibilidade tem mltiplas causas. Primeiro, pode existir uma real
impossibilidade fsica, devido ausncia de conectividade ou falhas na rede ou ainda falha do servidor.
Segundo, pode ser inconveniente efectuar a comunicao devido a razes econmicas ou problemas de
bateria em dispositivos mveis. Por m, existem situaes em que esse acesso pode ser inapropriado,
devido excessiva latncia das comunicaes, excesso de carga nos servidores durante picos de activi-
dade ou mesmo devido ao modelo das aplicaes (por exemplo, num editor cooperativo assncrono o
utilizador deve produzir as suas contribuies de forma independente [116]).
Para fornecer uma elevada disponibilidade de servio usual recorrer replicao dos dados. A
existncia de vrias cpias dos dados, apesar de eliminar o ponto central de falha, no suciente para
2.3. PRINCPIOS 13
garantir a disponibilidade dos dados em todas as situaes (por exemplo, em situaes de desconexo).
Para ultrapassar situaes de desconexo (com todas as rplicas) necessrio manter cpias locais dos
dados. Nestas condies, o servio assegurado recorrendo s cpias locais.
O servio de gesto de dados fornece dois tipos de operao: leitura e escrita. Embora existam
aplicaes em que apenas necessrio ler os dados, num nmero signicativo de aplicaes necessrio
permitir aos utilizadores modicarem os dados. Assim, a disponibilidade do servio de gesto de dados
deve considerar no s a possibilidade de ler os dados, mas tambm de os modicar (independentemente
da conectividade existente).
Numa situao em que a conectividade no total e em que existem computadores desconectados
durante longos perodos, os esquemas que garantem uma consistncia forte [37] (por exemplo, baseados
na utilizao de trincos (locks)) apresentam uma baixa taxa de disponibilidade para escrita [30]. Em
particular, torna-se impossvel garantir uma consistncia forte para as rplicas mantidas num compu-
tador desconectado sem impedir que os dados possam ser modicados. Por um lado, as modicaes
executadas aps o momento da desconexo por outros computadores so desconhecidas. Por outro lado,
as modicaes executadas localmente no podem ser propagadas para os outros computadores. As-
sim, para permitir a continuidade do servio em situaes de desconexo, necessrio recorrer a cpias
fracamente consistente, permitindo aos utilizador ler e modicar qualquer rplica
4
.
Quando existe conectividade entre os computadores que mantm rplicas dos dados, podem existir
condies que tornam aceitvel ou recomendvel a fraca consistncia das rplicas. Neste caso possvel
evitar os custos da sincronizao entre vrias rplicas para modicar os dados e utilizar comunicao
retardada (lazy) para propagar as modicaes.
2.3.2 Reconciliao dependente da situao
A utilizao de um modelo de replicao optimista com uma poltica de acesso aos dados l qual-
quer/escreve qualquer rplica permite a execuo concorrente de modicaes sobre um mesmo ob-
jecto. Estas modicaes, efectuadas em vrios uxos de actividade [41], podem originar a divergncia
das rplicas dos objectos. Para lidar com este problema, o servio de gesto de dados deve possuir um
mecanismo de reconciliao.
Dos exemplos apresentados na seco 2.2 possvel vericar que existem diferentes formas de tratar
as modicaes concorrentes e que as propriedades desejveis da reconciliao de vrias rplicas variam
para diferentes aplicaes. Por exemplo, tanto no sistema de conferncia assncrono como na agenda
partilhada, as vrias rplicas podem ser actualizadas aplicando as modicaes efectuadas por uma or-
4
Note-se que a consistncia fraca entre as rplicas de um sistema no impede que possa existir uma rplica que mantenha o
estado ocial dos dados, como se discute na seco 4.1.
dem apropriada. No sistema de conferncia podem inserir-se as novas mensagens usando uma ordem
causal porque no necessrio obter um estado comum (mas apenas manter as dependncias entre as
mensagens). Numa agenda partilhada necessrio usar uma ordem total para garantir a convergncia
das vrias rplicas da agenda. Finalmente, no exemplo do editor cooperativo, a simples execuo das
operaes por uma dada ordem no suciente porque, no caso de existirem modicaes conituantes,
se pretendem manter as vrias verses.
Muitos algoritmos foram propostos para lidar com as modicaes concorrentes. Entre estes, podem
referir-se como exemplo os algoritmos baseados na tcnica desfazer-refazer (undo-redo) [17, 81], na
transformao de operaes [46, 159], na explorao de propriedades semnticas [161, 79, 168], na
ordenao de operao usando propriedades semnticas [85, 123], na criao de mltiplas verses [24,
101, 88]. No entanto, parece no existir nenhum mtodo ideal para todas as situaes. Os exemplos
anteriores sugerem que diferentes situaes devem ser tratadas de forma diferente. A melhor estratgia
deve ser escolhida em funo das caractersticas especcas de cada aplicao ou de cada operao
executada.
Muito sistemas permitem que a estratgia de reconciliao seja adaptada por cada aplicao. Por
exemplo, no sistema Coda [87], cada aplicao pode fornecer os seus programas de reconciliao que
actuam com base no estado das rplicas dos cheiros. No sistema Bayou [161], a estratgia de reconci-
liao consiste em executar, em todas as rplicas, todas as operaes (deterministas) pela mesma ordem,
podendo cada operao conter cdigo especco de deteco e resoluo de conitos.
Nesta dissertao prope-se que, alm de permitir a adaptao da estratgia s caractersticas es-
peccas de cada aplicao, se permita tambm que, em cada aplicao, seja usada a estratgia mais
apropriada face semntica da aplicao. Assim, possvel usar em cada aplicao a estratgia que
permite criar a soluo desejada de forma mais simples. No captulo 3 apresenta-se um sistema que
permite esta adaptabilidade. Esta aproximao permite ainda criar catlogos de solues reutilizveis
em diferentes aplicaes com caractersticas semelhantes.
2.3.3 Replicao baseada na propagao de operaes
Num sistema baseado em replicao optimista necessrio lidar com modicaes executadas con-
correntemente. Existem duas alternativas para propagar estas modicaes entre as vrias rplicas de
um objecto. A primeira consiste em propagar o novo estado da rplica aps a execuo das modica-
es [80, 87, 66]. Neste caso, o mecanismo de reconciliao usa o estado das vrias rplicas dos dados
para obter o estado nal de cada rplica (que pode, eventualmente, conter mltiplas verses dos dados). A
segunda alternativa consiste em propagar as operaes executadas para modicar os dados [161, 79, 85].
Neste caso, o mecanismo de reconciliao usa o estado inicial dos dados e as operaes efectuadas para
2.3. PRINCPIOS 15
obter o estado nal de cada rplica.
Um dos aspectos a considerar sobre a forma de propagao das modicaes o trfego na rede
induzido por cada um dos mtodos. Quando se propaga o estado necessrio propagar uma cpia do
objecto entre as rplicas. Por exemplo, se o objecto que estamos a considerar um cheiro, necessrio
propagar o novo contedo do cheiro (utilizando algumas optimizaes possvel propagar apenas as
partes dos cheiros que foram alteradas [164]). No caso de terem existido vrias modicaes ao mesmo
objecto numa rplica, apenas o estado nal propagado. Na propagao de operao, todas as operaes
efectuadas so propagadas. No entanto, possvel reduzir o nmero de operaes a propagar removendo
as operaes cujos efeitos so absorvidos por outras operaes ou comprimindo vrias operaes numa
s (por exemplo, o algoritmo de compresso de uma sequncia de operaes apresentado na seco
10.4.2).
O trfego induzido por cada um dos mtodos depende, em grande parte, do modo como o sistema
utilizado, da dimenso dos objectos e das operaes disponveis no sistema, e da ecincia das optimi-
zaes executadas. Este facto demonstrado de forma simples pelos exemplos seguintes. Num primeiro
exemplo, consideremos um inteiro ocupando 4 bytes que incrementado 1000 vezes durante um perodo
de desconexo. No caso da propagao do estado, apenas necessrio propagar o estado nal do objecto
4 bytes. No caso de propagao de operaes necessrio propagar as 1000 operaes efectuadas. Se
for possvel comprimir estas operaes numa s (incrementar 1000 vezes um inteiro equivalente a adi-
cionar 1000 a esse inteiro), ento apenas teremos de propagar uma operao. Neste caso, a propagao
do estado mais eciente (ou pelo menos to eciente no caso de ser possvel comprimir as operaes
executadas). Num segundo exemplo, consideremos uma lista de 1000 inteiros que se pretendem incre-
mentar. Propagando o estado necessrio propagar todos os inteiros. Propagando as operaes, basta
propagar uma operao que incremente cada um dos 1000 inteiros.
Este problema foi estudado no contexto do sistema de cheiros distribudo Coda [96] utilizando
vrias aplicaes no interactivas. Neste contexto, obtiveram redues do trfego gerado por um factor
de 20 quando utilizavam a propagao de operaes (por comparao com a tradicional propagao dos
cheiros).
Um segundo aspecto a considerar o da relao entre o modo de propagao das modicaes e
as estratgias de reconciliao usadas. Embora, como j discutimos anteriormente, no exista nenhum
mtodo ideal para tratar as modicaes concorrentes, o uso de informao semntica foi identicado
como a chave para uma boa soluo [147, 161, 79, 87]. Dois tipos de informao semntica podem
ser usados durante a reconciliao. Primeiro, a informao semntica associada aos dados manipulados
este tipo de informao pode ser usada em qualquer uma das aproximaes. Segundo, a informao
semntica associada s operaes executadas. Quando se propaga o estado, apenas possvel tentar
inferir quais as operaes executadas a partir do novo estado do objecto (por comparao com o estado
inicial). Quando se propagam as operaes possvel associar a cada operao informao semntica
usada durante a reconciliao. Por exemplo, podem incluir-se regras de deteco e resoluo de conitos.
Assim, e para maximizar a informao semntica que pode ser usada durante a reconciliao, as solues
apresentadas nesta dissertao so baseadas na propagao de operaes.
2.3.4 Informao sobre a evoluo dos dados e da actividade cooperativa
Quando se permite que mltiplos utilizadores modiquem concorrentemente dados partilhados, muitas
vezes importante fornecer informao sobre a sua evoluo. No exemplo do editor cooperativo apre-
sentado anteriormente, um utilizador pode estar interessado em saber quais as alteraes efectuadas ao
documento recentemente. O acesso a este tipo de informao importante para o sucesso das actividades
cooperativas, como foi reconhecido na literatura de trabalho cooperativo h algum tempo [47, 65, 43]. A
esta informao d-se o nome de informao de awareness
5
.
Num sistema baseado em replicao optimista necessrio reconciliar modicaes conituantes.
Assim, comum que o resultado nal duma operao (i.e., o modo como a operao afecta o estado
ocial dos dados) apenas seja denitivamente conhecido aps a reconciliao das vrias rplicas.
Das caractersticas anteriores resultam trs factos importantes. Primeiro, os utilizadores no tm
geralmente conhecimento imediato do resultado das operaes que submetem. Este facto sugere a ne-
cessidade de existir um mecanismo que permita noticar os utilizadores do resultado nal das operaes.
Por exemplo, na agenda partilhada os utilizadores devem ser informados do resultado denitivo das suas
marcaes.
Segundo, a informao sobre a evoluo dos dados apenas pode ser criada aquando do processo
de reconciliao porque apenas neste momento determinado o resultado nal da operao. Assim, a
criao da informao deve estar integrada com o mecanismo de reconciliao.
Finalmente, os utilizadores podem no estar a usar o computador ou a aplicao em que executaram
as operaes quando o resultado nal destas determinado. Assim, se se pretender informar imediata-
mente o utilizador do resultado das suas operaes, pode no ser suciente propagar o resultado para a
mquina em que foram executadas, porque esta mquina pode estar desligada/desconectada ou o utiliza-
dor pode no estar a utiliz-la. Actualmente, com o uso generalizado de telefones mveis, geralmente
possvel enviar informao para os utilizadores atravs de mensagens curtas (por exemplo, o servio
SMS nas redes GSM). Assim, o sistema deve usar os meios disponveis para propagar a informao
5
O termo ingls awareness , por vezes, traduzido pelos termos conscincia, conhecimento ou sensibilizao. No entanto,
por se considerar que a utilizao destas tradues no incluem o sentido completo do termo original, obscurecendo o texto,
decidiu-se utilizar o termo ingls em itlico.
2.3. PRINCPIOS 17
sobre a evoluo dos dados para os utilizadores, mesmo aqueles que podem ser considerar exteriores ao
sistema.
Dos exemplos apresentados, necessrio realar que no existe um modo nico de fornecer infor-
mao sobre a evoluo dos dados. Nuns casos, esta informao deve ser apresentada quando se acede
aos dados o editor cooperativo um exemplo. Noutros casos necessrio propagar a informao
directamente para os utilizadores a agenda partilhada um exemplo. Assim, o modo como esta infor-
mao tratada pelo sistema deve ser denida em funo das caractersticas especcas da aplicao (e
muitas vezes dentro de uma mesma aplicao necessrio adaptar o modo de tratamento situao e ao
utilizador).
Embora as caractersticas apresentadas anteriormente sejam comuns generalidade dos sistemas que
suportam operao desconectada [115, 85, 59, 161, 79, 87], o problema de fornecer informao sobre
a evoluo dos dados geralmente negligenciada. Este facto leva os programadores a implementar
solues ad-hoc sem o conveniente suporte por parte do sistema.
Nesta dissertao apresentam-se solues em que a criao e o tratamento da informao sobre a
evoluo dos dados esto completamente integrados no sistema. Todas as operaes efectuadas pelos
utilizadores podem gerar informao e o modo como esta informao tratada pode depender da aplica-
o ou situao. O sistema fornece suporte para a propagao da informao para os utilizadores atravs
de mecanismos exteriores ao sistema. O sistema tambm permite que esta informao seja mantida
com os dados para posterior acesso pelos utilizadores. Alguns sistemas de suporte ao trabalho coope-
rativo [16, 44, 97] incluem este tipo de mecanismos. No entanto, nesta dissertao apresenta-se uma
nova aproximao atravs da integrao destes mecanismos ao nvel dos tipos de dados e das operaes
denidas.
2.3.5 Replicao secundria parcial
A replicao dos dados em vrios servidores no garante a disponibilidade dos dados durante os perodos
de desconexo. Para tal, comum recorrer a um mecanismo de replicao secundria (caching) para
manter cpias parciais dos dados nos computadores portteis.
No sistema Coda [87], bem como noutros sistemas de cheiros distribudos, a unidade de replicao
secundria o cheiro. Esta aproximao permite uma semntica simples e clara de acesso aos cheiros:
ou possvel aceder ao cheiro completo ou no possvel aceder a nenhuma parte do cheiro (quando
no existe uma cpia local). Quando os cheiros so muito longos, pode ser impossvel a um dispositivo
mvel com recursos limitados manter cpias de cheiros completos. Adicionalmente, o tempo necess-
rio para transmitir uma cpia total dum cheiro pode ser inaceitvel este problema acentua-se para
dispositivos mveis que utilizam redes de comunicao sem os com reduzida largura de banda.
Nas bases de dados orientadas para os objectos (BDOO), os objectos so a unidade de manipulao
dos dados. No entanto, os objectos so geralmente agrupados em pginas aquando da sua criao e,
em alguns sistemas, reagrupados usando algoritmos de agrupamento (clustering) [165, 27, 55]. Para
melhorar o desempenho, as BDOO incluem um subsistema de replicao secundria (caching), no qual
os clientes ou os servidores mantm em memria cpias de um conjunto de objectos ou pginas de
objectos [23, 109].
Para permitir a operao durante perodos de desconexo necessrio obter cpias de todos os ob-
jectos que vo ser acedidos. No entanto, como os objectos so geralmente de pequena dimenso (por
exemplo, na base de dados dos testes de referncia OO7 [22], a dimenso mdia dos objectos 51 bytes
no sistema Thor [100]) e em muito elevado nmero, determinar os objectos que devem ser replicados
extremamente complexo. Note-se que o agrupamento dos objectos em pginas no simplica o processo
de anlise porque os objectos e as suas ligaes tm de ser tratados individualmente.
Apesar de os objectos serem a unidade de manipulao, as aplicaes tendem a manipular objectos
complexos compostos por um grafo de objectos simples. O sistema DOORS, apresentado no captulo 3
desta dissertao, adopta uma soluo de replicao secundria parcial em que se explora esta obser-
vao. Assim, a unidade de replicao secundria o grupo de objectos fortemente interligados que
denem um objecto complexo por exemplo, num documento estruturado, uma seco representa uma
unidade de replicao secundria (caching), embora seja composta por mltiplos objectos. Como cada
objecto complexo dene uma caixa negra (i.e., apenas pode ser acedido atravs da sua interface), o
sistema de replicao apenas lida com objectos complexos. Os programadores, ao desenharem os ob-
jectos manipulados pelas aplicaes so responsveis por identicar os objectos complexos. Assim, a
granularidade da replicao secundria denida tendo em conta a semntica dos dados.
Nos sistemas de bases de dados relacionais que suportam computao mvel [115, 142] usual
manter cpias de subconjuntos dos dados, os quais so seleccionados atravs de interrogaes base de
dados (usando variantes do comando select). Desta forma, pode adaptar-se a granularidade das cpias
locais s necessidades especcas de cada utilizador. A semntica dos dados e suas interligaes devem
ser exploradas nas interrogaes para obter subconjuntos coesos de dados (i.e., mantendo sempre que
possvel a integridade referencial). No sistema Mobisnap, apresentado no captulo 7 desta dissertao,
usa-se uma soluo semelhante.
Nas solues apresentadas nesta dissertao apenas se fornecem os mecanismos que permitem de-
nir, obter e manter cpias parciais locais dos dados. O problema de determinar de forma eciente quais
os dados que devem ser obtidos para suportar a operao desconectada est fora do mbito deste trabalho.
Algumas solues so apresentadas em [87, 91].
2.3. PRINCPIOS 19
2.3.6 Invocao cega
Durante os perodos de desconexo, o acesso aos dados garantido recorrendo a cpias locais os
utilizadores acedem e modicam estas cpias. No entanto, possvel que no exista uma cpia local
dos dados que os utilizadores pretendem manipular. Nesta situao, obviamente impossvel ao sistema
disponibilizar operaes de leitura que devolvam o estado actual dos dados (ou mesmo, uma verso
recente). Nos sistemas de gesto de dados distribudos, este facto impede normalmente os utilizadores
de executarem quaisquer operaes sobre os dados.
No entanto, existem situaes em que possvel permitir aos utilizadores uma forma limitada de
acesso aos dados, assim minimizando os problemas decorrentes das faltas na replicao secundria, i.e.,
da inexistncia de uma cpia local de um objecto acedido pelo utilizador. Por exemplo, numa agenda
partilhada parece razovel permitir a submisso de novas marcaes sem acesso a uma cpia da agenda.
Estes pedidos devem ser conrmados atravs do mecanismo automtico de consenso global, como todas
os outros pedidos.
O princpio subjacente consiste em permitir a submisso de operaes que modiquem objectos no
disponveis localmente, deixando aos utilizadores a deciso sobre quais as situaes em que aconselh-
vel produzir novas contribuies
6
. No mbito da evoluo do estado global dos dados, estas operaes
devem ser tratadas de modo idntico a todas as outras, i.e., estas operaes so propagadas para os ser-
vidores onde so integradas no estado dos dados (de acordo com o mecanismo de reconciliao usado).
Um aspecto a considerar o modo como estas operaes so tratadas localmente. Podemos conside-
rar dois casos distintos. No primeiro caso, o tipo de objectos manipulados pela aplicao desconhecido
7
Nesta situao, apenas possvel aceitar as operaes executadas pelo utilizador. O sistema no pode
sequer vericar localmente se as operaes so vlidas (por exemplo, numa sistema de bases de dados
impossvel vericar se as operaes actuam apenas sobre tabelas existentes).
Uma segunda situao aquela em que, apesar de no se ter uma cpia local dos dados, so co-
nhecidos os seus tipos. Neste caso, existem situaes em que pode ser interessante criar uma cpia de
substituio dos objectos e executar as operaes localmente sobre essa cpia. No exemplo do editor coo-
perativo descrito anteriormente, pode ter-se uma cpia parcial dum documento estruturado que contenha
apenas a estrutura do documento e algumas seces. Se o utilizador quiser criar uma nova verso duma
seco no presente localmente, possvel criar um objecto de substituio que represente a seco. O
utilizador pode ento executar operaes sobre o objecto de substituio, introduzindo novas seces ou
modicando as seces introduzidas anteriormente. O resultado observado na cpia de substituio deve
6
Note-se que um utilizador pode ter um conhecimento aproximado do estado de um objecto apesar de o computador que
usa no possuir nenhuma cpia desse objecto. Este conhecimento pode ter sido obtido num acesso recente efectuado noutro
computador ou atravs de meios exteriores ao sistema.
7
Numa sistema de bases de dados relacionais, esta situao equivale a ser desconhecido o esquema da base de dados.
ser considerado provisrio como acontece normalmente com as invocaes executadas no cliente. O
resultado denitivo das operaes apenas determinado aps a sua integrao no estado ocial do ob-
jecto. A criao de cpias de substituio permite s aplicaes manipular de forma semelhante todos os
objectos (embora a interface da aplicao deva reectir o facto de se tratar de uma cpia de substituio).
Nas solues apresentadas nesta dissertao possvel executar (submeter) operaes sobre dados
no replicados localmente. No captulo 3 apresenta-se um sistema que permite tambm a utilizao de
objectos de substituio. Embora esta tcnica no possa ser usada em todas as situaes, os exemplos
apresentados demonstram a sua utilidade quando usada convenientemente. No captulo 7 apresenta-
-se um sistema que permite a submisso de transaces que no podem ser conrmadas com os dados
disponveis localmente.
Que o autor tenha conhecimento, nenhum outro sistema implementa estas ideias, apesar de vrios
serem baseados na propagao de operaes [123, 108, 161]. Por exemplo, no sistema Rover [79], as
operaes executadas nas cpias locais dos objectos so propagadas para o servidor atravs dum meca-
nismo de RPC diferido. No entanto, apenas possvel executar operaes sobre objectos disponveis
localmente.
2.3.7 Preveno de conitos
A necessidade de reconciliar as modicaes executadas independentemente leva a que o resultado ou
efeito de uma operao no seja geralmente conhecida imediatamente quando a operao executada. O
resultado denitivo de uma operao apenas determinado aps a sua integrao nal no estado ocial
dos dados. Este facto comum nos sistemas baseados em replicao optimista [87, 161, 59, 115].
O conhecimento imediato dos resultados das operaes executadas importante em algumas aplica-
es. Por exemplo, num sistema de reserva de lugares para comboios importante que os utilizadores
possam saber imediatamente o resultado dos seus pedidos.
A possibilidade de obter o resultado de uma operao de forma independente elimina a necessidade
de comunicar de forma sncrona com o servidor. Assim, possvel reduzir o tempo de processamento
de uma operao executando-a localmente. Dado que a latncia das comunicaes tende a manter-se
sem alteraes signicativas (ao contrrio da abilidade e largura de banda), esta propriedade pode ser
importante mesmo quando possvel contactar o servidor.
Adicionalmente, possvel utilizar os recursos comunicacionais disponveis de forma mais eciente
propagando conjuntos de operaes de forma assncrona. Oservidor pode tambmadiar o processamento
das operaes para os momentos de carga mais reduzida.
A forma de garantir o sucesso de uma operao de forma independente consiste em restringir as
operaes que podem ser executadas concorrentemente, assim garantindo que no surgem conitos (in-
2.3. PRINCPIOS 21
solveis). As tcnicas de trincos (locks) [17, 60] usadas tradicionalmente em sistemas distribudos so
um exemplo extremo desta estratgia: o utilizador que possui um trinco pode modicar os dados en-
quanto todos os outros esto impedidos de efectuar qualquer modicao.
Outro exemplo dessa estratgia consiste em utilizar a informao semntica associada aos tipos de
dados representados e s operaes que podem ser executadas sobre esses tipos de dados para garantir o
sucesso de operaes executadas concorrentemente. Por exemplo, sempre possvel garantir o sucesso
de uma operao de incremento executada sobre um nmero inteiro (de dimenso no limitada). Esta
ideia pode ser estendida limitando as operaes que podem ser executadas (ou, o que equivalente, res-
tringindo os valores possveis de cada rplica). Estas ideias foram propostas anteriormente para garantir
o sucesso de operaes executadas concorrentemente [111, 168].
No captulo 7 apresentamos um sistema de reservas que permite garantir independentemente o su-
cesso (de algumas) das operaes executadas numa base de dados para computao mvel. Quando
impossvel garantir o sucesso de uma operao, possvel execut-la de forma optimista (sendo o re-
sultado nal determinado aquando da sua integrao na verso ocial dos dados). Este sistema adapta e
estende algumas ideias propostas anteriormente [60, 58, 111] a um ambiente de computao mvel e a
um sistema de bases de dados SQL.
2.3.8 Suporte para os programadores
Nesta dissertao apresentam-se dois sistemas de gesto de dados para ambientes de computao mvel.
Nas seces anteriores discutiram-se os princpios gerais adoptados nesses sistemas. Existem duas ca-
ractersticas importantes que devem ser tidas em considerao. A primeira, a necessidade de permitir
o desenvolvimento de solues especcas para cada aplicao. A segunda, a necessidade de permitir
que as diferentes solues sejam denidas e utilizadas da forma mais simples possvel.
A necessidade de permitir o desenvolvimento de solues especcas para cada aplicao foi justi-
cada nas seces anteriores, com especial destaque para o problema da reconciliao e tratamento da
informao sobre a evoluo dos dados. Duas aproximaes podem ser consideradas para fornecer esta
exibilidade. Primeiro, possvel denir um sistema com uma estratgia nica que pode ser adaptada a
cada situao especca. Esta aproximao adoptada em vrios sistema distribudos de gesto de dados
os sistemas Coda [87] e Bayou [161] so apenas dois exemplos. A soluo apresentada no cap-
tulo 7 desta dissertao tambm adopta esta aproximao. A segunda aproximao consiste em permitir
a adopo de estratgias diferentes em diferentes situaes. A ideia consiste em permitir que se adopte
a estratgia que permite a soluo mais simples em cada situao. O sistema Globe [12] e o sistema
proposto em [20] usam esta aproximao. A soluo apresentada no captulo 3 desta dissertao tambm
adopta esta aproximao.
No entanto, a exibilidade no desenvolvimento de novas soluo no suciente para suportar con-
venientemente os programadores na criao de novas aplicaes. Um aspecto a ter em considerao o
facto de os programadores que vo criar novas aplicaes no serem (necessariamente) especialistas em
sistemas distribudos. Desta forma, necessrio permitir que estes programadores utilizem as tcnicas
de sistemas distribudos de forma simples.
Nos sistemas que apenas permitem a adaptao duma estratgia pr-denida, necessrio que essa
adaptao possa ser efectuada de forma simples. Por esta razo, as solues apresentadas no sistema
Mobisnap (captulo 7) so baseados em mecanismos utilizados de forma generalizada transaces e
linguagem PL/SQL. Assim, os programadores podem denir as suas solues usando conceitos que lhe
so familiares.
Nos sistemas que permitem a utilizao de diferentes estratgias necessrio que os programadores
de aplicaes possam seleccionar e adaptar a estratgia que pretendem utilizar de forma simples.
tambm necessrio que seja possvel denir novas estratgias. No sistema Doors (captulo 3) denimos
um framework de componentes que permite aos programadores compor uma soluo global, reutilizando
solues pr-denidas para os diferentes problemas. Para cada um dos problemas, possvel denir
novas solues criando novos componentes (a decomposio dos problemas relacionados com a gesto
dos dados em vrios componentes permite concentrar a ateno num nico problema de cada vez).
2.4 Sumrio
Nesta seco apresentaram-se os princpios fundamentais adoptados nas solues de gesto de dados
propostas nesta dissertao. Para motivar estes princpios, descreveu-se a utilizao de um conjunto de
aplicaes tpicas de um ambiente de computao mvel.
Vrios sistemas propuseram anteriormente solues de gesto de dados para ambientes de computa-
o mvel que colocavam em prtica os princpios identicados. As solues apresentadas, inicialmente
muito rgidas, foram-se tornando mais exveis e adaptadas aos vrios problemas atravs da explorao
da informao semntica.
As solues propostas nesta dissertao para colocar em prtica os vrios princpios identicados
tm em comum a preocupao de explorar ao mximo a informao semntica disponvel. No prximo
captulo apresentam-se as solues propostas no mbito de um repositrio de objectos desenhado para
suportar o desenvolvimento de actividades cooperativas tipicamente assncronas.
Captulo 3
Apresentao do sistema DOORS
Nos prximos captulos descreve-se um sistema de gesto de dados desenhado com o objectivo de gerir
dados partilhados em actividades cooperativas tipicamente assncronas: o sistema DOORS [129, 130,
131, 132] (DAgora Object-Oriented Replicated Store). Este sistema foi desenvolvido no mbito do pro-
jecto DAgora [34]. O objectivo deste projecto era o estudo e desenvolvimento de suporte computacional
para actividades cooperativas. No mbito deste projecto foram estudados vrios problemas, entre os
quais: o suporte para aplicaes cooperativas sncronas [156]; a coordenao de actividades cooperati-
vas [40, 39]; e a disseminao de informao de awareness [45]. Estes problemas esto fora do mbito
desta dissertao, a qual se restringe aos problemas de gesto de dados em ambientes distribudos de
larga-escala.
O sistema DOORS um sistema de gesto de dados que fornece elevada disponibilidade de leitura
e escrita num ambiente de computao mvel usando um modelo de replicao optimista. O sistema
permite o desenvolvimento de solues especcas para cada tipo de dados. Para tal, deniu-se um
framework de componentes que decompe os vrios aspectos relacionados com a gesto de dados par-
tilhados em vrios componente. Neste captulo apresenta-se brevemente o funcionamento do sistema e
detalha-se o framework de componentes.
No prximo captulo discutem-se, de forma mais pormenorizada, alguns dos aspectos de gesto de
dados que dependem do tipo de aplicao. Entre estes, abordam-se o problema da reconciliao, da
invocao cega e da integrao de sesses sncronas. No captulo 5 apresentam-se vrias aplicaes que
exemplicam a utilizao do sistema DOORS e, em particular, do seu framework de componentes. A
arquitectura do sistema DOORS, incluindo os protocolos implementados no prottipo do sistema, so
detalhados no captulo 6.
De seguida, descreve-se o modelo geral do sistema, incluindo uma breve descrio da sua arquitec-
tura e do modo de funcionamento dos objectos geridos pelo mesmo.
23
24 CAPTULO 3. APRESENTAO DO SISTEMA DOORS

Legenda
Servidor
Cliente
Sub-objecto
Aplicao
sub-objectos
modificaes
propagao
epidmica
sub-objectos
modificaes
sub-objectos &
modificaes
sesso
sncrona

Figura 3.1: Arquitectura do sistema DOORS composta por computadores com diferentes conguraes.
3.1 Modelo geral
O sistema DOORS um repositrio distribudo de objectos baseado numa arquitectura cliente esten-
dido/servidor [78]. O sistema manipula objectos estruturados segundo o modelo de componentes DO-
ORS, que se designam por coobjectos. Um coobjecto representa um tipo de dados possivelmente com-
plexo, que pode ser formado por uma composio de outros objectos. Estes objectos so agrupados em
conjuntos (clusters) de objectos relacionados, que se designam por subobjectos. Por exemplo, um co-
objecto pode representar um documento estruturado como esta dissertao. A estrutura do documento e
cada um dos elementos bsicos (por exemplo, os captulos desta dissertao) podem ser denidos como
subobjectos.
Os coobjectos relacionados so agrupados em conjuntos que representam um espao de trabalho co-
operativo (collaborative workspace) e incluem os dados associados a uma sesso de trabalho cooperativo
ou a um grupo de trabalho cooperativo. Estes conjuntos de coobjectos so designados por volumes [87].
O sistema DOORS composto por dois componentes, clientes e servidores, como se representa na
gura 3.1. Em geral, os servidores executam em mquinas xas com boa conectividade. Os clientes
podem executar em mquinas xas ou mveis e a sua conectividade geralmente varivel. Qualquer
mquina pode actuar simultaneamente como cliente e servidor. Por vezes, e quando essa designao
no cause confuso, tambm se designa de servidor (cliente) a mquina em que executa o componente
servidor (cliente) do sistema DOORS.
Para fornecer uma elevada disponibilidade de leitura e escrita, os coobjectos do sistema DOORS so
replicados usando um modelo de replicao optimista. Assim, qualquer rplica pode ser modicada de
forma independente, maximizando a possibilidade de os utilizadores efectuarem as suas contribuies
3.1. MODELO GERAL 25
para a actividade cooperativa.
Cada servidor replica um conjunto de volumes de coobjectos. Para cada volume, replica todos os
coobjectos que esto contidos nesse volume. O estado destas rplicas sincronizado durante sesses de
sincronizao epidmicas estabelecidas entre pares de servidores. A replicao nos servidores tem por
objectivo mascarar as falhas nos servidores e no sistema de comunicao.
Os clientes executam um mecanismo de replicao secundria (os caching), mantendo uma cache
1
com cpias parciais de um conjunto de coobjectos. Uma cpia parcial de um coobjecto inclui apenas um
subconjunto de todos os subobjectos que compem um coobjecto. Os clientes sincronizam o estado das
cpias locais com os servidores e com outros clientes. A replicao parcial nos clientes tem por objectivo
mascarar os perodos de desconexo, permitindo aos utilizadores continuarem a ler e modicar os dados
partilhados.
As aplicaes que utilizam o sistema DOORS executam nos clientes e modicam os coobjectos
atravs da execuo de mtodos dos subobjectos os utilizadores cooperam entre si modicando dados
partilhados. De seguida, apresenta-se o modelo de acesso aos coobjectos.
3.1.1 Modelo de manipulao dos coobjectos
Em geral, as aplicaes acedem aos coobjectos usando o modelo de acesso obtm/modica local-
mente/submete modicaes. Assim, quando uma aplicao solicita o acesso a um coobjecto, o cliente,
caso no possua uma cpia local, obtm-na a partir de um servidor (ou, caso tal no seja possvel, de
outro cliente). De seguida, o cliente cria uma cpia privada do coobjecto e entrega-a aplicao.
Uma aplicao manipula a cpia privada do coobjecto e os seus subobjectos de forma semelhante a
um grafo de objectos comuns, i.e., usando os seus mtodos para aceder e modicar o estado dos objectos
e navegar na estrutura denida. As operaes de modicao executadas pelas aplicaes so registadas
no coobjecto de forma transparente para a aplicao e sem interveno do cliente do sistema DOORS
(ver detalhes na seco 3.2.2.2). Este registo consiste na sequncia de invocaes de mtodos
2
efectuadas
pela aplicao.
Inicialmente a cpia privada de um coobjecto inclui apenas referncias para um (ou vrios) subob-
jecto raiz. Os subobjectos apenas so instanciados quando necessrio (i.e., quando so acedidos). Nesse
momento, o cliente cria uma cpia privada do subobjecto
3
e liga-a cpia privada do coobjecto todo
este processo transparente para a aplicao.
1
Usa-se o termo cache para designar o espao usado para guardar rplicas secundrias dos dados, neste caso, rplicas
parciais dos coobjectos.
2
A invocao de um mtodo tambm denominada de operao.
3
Para tal, o cliente pode ter necessidade de contactar um servidor se a sua cpia parcial do coobjecto no incluir o subobjecto
em questo.
Nas situaes em que o cliente no consegue obter uma cpia do subobjecto a que a aplicao est
a aceder, o mecanismo de invocao cega do sistema DOORS permite que as operaes de modicao
executadas sejam igualmente registadas, apesar de no serem executadas. O mecanismo de invocao
cega permite ainda criar cpias de substituio dos subobjectos. Assim, possvel observar o resultado
esperado das operaes executadas pelos utilizadores.
O mecanismo de invocao cega, cujos princpios foram discutidos na seco 2.3.6, pode ser con-
siderado como uma extenso ao modelo de replicao optimista, permitindo submeter operaes de
modicao sobre dados dos quais no se possui uma rplica local. Esta tcnica permite mascarar as
falhas na replicao secundria e maximizar a disponibilidade dos dados.
Aps manipular a cpia privada de um coobjecto, se o utilizador decidir gravar as modicaes
efectuadas, a sequncia de invocaes registada na cpia privada do coobjecto transferida para o cliente.
O cliente armazena esta sequncia de invocaes de forma estvel at ter possibilidade de a propagar para
um servidor.
O servidor, ao receber de um cliente uma sequncia de invocaes, entrega-a rplica local do
coobjecto. da responsabilidade da cpia do coobjecto presente no servidor armazenar e processar estas
invocaes.
Os servidores sincronizam o estado das suas rplicas, sincronizando o conjunto de invocaes co-
nhecidas. Para tal, estabelecem-se sesses de sincronizao epidmicas entre pares de servidores. Este
modelo de sincronizao garante que, no nal, todos os servidores receberam todas as invocaes efec-
tuadas, quer directa, quer indirectamente. As sesses de sincronizao podem ser estabelecidas sobre
vrios transportes, sncronos ou assncronos. Os servidores obtm as invocaes a propagar, e entregam
as invocaes recebidas, s rplicas locais dos coobjectos. sempre da responsabilidade das rplicas dos
coobjectos armazenar e processar estas invocaes.
Adicionalmente, cada servidor propaga, para os outros servidores que replicam o volume, atravs
dum sistema de disseminao de eventos no vel, as sequncias de invocaes recebidas directamente
dos clientes (aps estas terem sido estampilhadas pela rplica local). Esta propagao tem por objec-
tivo diminuir a divergncia momentnea entre as vrias rplicas (resultado de conhecerem diferentes
subconjuntos de invocaes), aumentando a rapidez de propagao das modicaes.
3.1.2 Modelo de funcionamento do sistema
A breve descrio apresentada anteriormente permite constatar que o funcionamento do sistema DOORS
se baseia na cooperao entre o ncleo do sistema, responsvel pelas funcionalidades de gesto de dados
comuns, e os coobjectos, responsveis pelas solues especcas.
O ncleo do sistema apenas executa as tarefas comuns relacionadas com a gesto de dados partilha-

A
d
a
p
t
a
o

Gestor do
cluster
A
t
r
i
b
u
t
o
s

Cpsula
A
w
a
r
e
n
e
s
s

sub-objectos
Proxies dos sub-objectos
osroxies
A
p
l
i
c
a
o

Sistema
R
e
c
o
n
c
i
l
i
a
o

L
o
g

Figura 3.2: Framework de componentes DOORS.
dos. Por um lado, implementa as funcionalidades necessrias para que o sistema apresente uma elevada
disponibilidade de acesso, entre as quais: a gesto da liao de cada volume (i.e., do conjunto de servi-
dores que replica cada volume); a gesto da sincronizao dos dados entre os vrios servidores; e a gesto
das rplicas secundrias (cache) nos clientes. Por outro lado, o ncleo do sistema executa os servios
necessrios ao funcionamento dos coobjectos, entre os quais: a gesto dos recursos locais associados a
cada coobjecto (no cliente e no servidor); o servio de descoberta (de volumes); o servio de propaga-
o de mensagens de awareness; o servio de propagao sncrona de operaes (entre um cliente e um
servidor).
O sistema delega nos coobjectos a implementao da maioria dos aspectos relacionados com a gesto
dos dados partilhados. Entre estes aspectos, pode destacar-se a gesto da informao sobre as modica-
es executadas pelos utilizadores, o mecanismo de reconciliao das vrias rplicas nos servidores e a
gesto da informao de awareness.
Esta soluo contribui para a exibilidade do sistema DOORS, permitindo a denio de solues
especcas para cada problema. No entanto, coloca um enorme responsabilidade na implementao dos
coobjectos, os quais tm de tratar de aspectos que normalmente so da responsabilidade do ncleo do
sistema. Para fazer face a este problema, o sistema DOORS dene um framework de componentes em
que se decompe o funcionamento de um coobjecto em vrios componentes (ver gura 3.2).
Usando este framework, possvel criar um coobjecto compondo um componente que implementa
o tipo de dados a criar, com um conjunto de componentes em que cada um implementa uma soluo
especca para um dos problemas identicados no framework. Assim, possvel reutilizar a mesma
soluo em diferentes coobjectos atravs da simples reutilizao do componente que implementa essa
soluo.
Esta aproximao adapta-se s caractersticas das aplicaes cooperativas, como apresentadas no ca-
ptulo 2, em que diferentes grupos de aplicaes usam as mesmas estratgias relativamente a diferentes
problemas, como por exemplo a reconciliao e o tratamento da informao de awareness. Adicional-
mente, esta aproximao permite aos programadores reutilizar tcnicas complexas de sistemas distribu-
dos sem terem de lidar com os detalhes de implementao dessas solues (os quais so encapsulados
nos componentes pr-denidos).
De seguida, apresenta-se o framework de componentes DOORS, explicando o modo como possvel
criar um novo coobjecto. Exemplos detalhados de coobjectos criados no mbito de aplicaes coopera-
tivas so descritos no captulo 5. O ncleo do sistema detalhado no captulo 6.
3.2 Framework de componentes: princpios gerais
O framework de componentes DOORS decompe um coobjecto num conjunto de componentes, cada
um tratando dum aspecto especco do funcionamento do coobjecto. Os vrios componentes interac-
tuam entre si para implementar uma soluo global de gesto de dados. As responsabilidades de cada
componente so bem-denidas e, tanto quanto possvel, isoladas. No entanto, algumas implementaes
de um componente podem exigir a implementao de uma dada funcionalidade noutro componente,
restringindo as composies possveis.
De seguida apresenta-se de forma breve o framework DOORS e o modo como os vrios componentes
interagem. Em particular, descreve-se o funcionamento de um coobjecto composto por um conjunto de
subobjectos. Na prxima seco detalha-se cada um dos componentes do framework e descrevem-se
alguns dos componentes pr-denidos no prottipo do sistema DOORS.
3.2.1 Subobjectos
Um coobjecto dene um tipo de dados, possivelmente complexo, especialmente desenhado para ser par-
tilhado por vrios utilizadores e manipulado concorrentemente por exemplo, um documento estrutu-
rado. Uma instncia de um coobjecto mantm uma representao do valor actual do tipo de dados atravs
de uma composio de subobjectos por exemplo, um subobjecto com a estrutura do documento e um
subobjecto por cada elemento.
Um subobjecto pode ser um objecto complexo constitudo por um conjunto de outros objectos (de-
nidos ao nvel da linguagem de programao usada para denir o subobjecto). No entanto, no mbito
de um coobjecto, um subobjecto representa uma caixa preta com um estado interno que apenas pode
ser acedido e modicado atravs da invocao de mtodos da interface que implementa. O subobjecto
constitui a unidade de manipulao dentro de um coobjecto. Os subobjectos so acedidos por navega-
o a partir de um subobjecto base (i.e., apesar de internamente os subobjectos terem um identicador
3.2. FRAMEWORK DE COMPONENTES: PRINCPIOS GERAIS 29
nico, uma aplicao nunca acede a um subobjecto usando directamente este identicador). Para tal, os
subobjectos podem manter referncias para outros subobjectos.
Embora um coobjecto inclua instncias de vrios outros componentes, so os subobjectos que re-
presentam o valor do tipo de dados que se pretende denir os outros componentes so usados para
controlar os vrios aspectos da partilha dos dados. Assim, pode dizer-se que o estado de um coobjecto
representado pelo estado dos subobjectos que o constituem e que reectem a execuo de uma determi-
nada sequncia de operaes. No entanto, de forma mais exacta, dever-se-ia considerar que o estado de
um coobjecto inclui tambm o estado dos outros componentes.
As aplicaes e os subobjectos no mantm referncias directas para um subobjecto. Estas refern-
cias so implementadas atravs de representantes de subobjectos (proxies) que implementam a mesma
interface dos subobjectos. O uso de representantes elimina a necessidade de interceptar as invocaes de
mtodos num subobjecto ao nvel do sistema de execuo dos programas.
Os representantes (proxies) permitem executar de forma simples as seguintes funcionalidades ne-
cessrias ao funcionamento do sistema DOORS. Primeiro, os representantes permitem interceptar as
invocaes de mtodos de um subobjecto e criar o necessrio registo de invocaes (esta caractersticas
fundamental num sistema de replicao baseado na propagao das modicaes como sequncias de
operaes). Segundo, os representantes permitem que apenas se instanciem os subobjectos quando
necessrio executar mtodos desses subobjectos. Terceiro, os representantes eliminam a necessidade de
modicar os apontadores usados para referenciar outros subobjectos quando um subobjecto instanci-
ado
4
. Quarto, os representantes encapsulam os identicadores dos subobjectos, os quais no so visveis
pelas aplicaes o acesso aos subobjectos efectua-se sempre por navegao (a partir de um objecto
base), como normal nas linguagens orientadas para os objectos.
A instanciao de um subobjecto executada pelo gestor de subobjectos (cluster manager) apenas
quando necessrio. O gestor de subobjectos mantm referncias para todos os subobjectos presentes em
memria de forma a garantir que apenas existe uma instncia de cada subobjecto.
Adicionalmente, o gestor dos subobjectos responsvel por manter referncias para o subobjecto
base (ou conjunto de subobjectos base) por exemplo, no documento estruturado, a estrutura principal
do documento o subobjecto base, o qual permite aceder aos outros subobjectos por navegao na
estrutura do documento. Todos os outros subobjectos so acedidos a partir destes por navegao. O
gestor dos subobjectos ainda responsvel por controlar a persistncia dos subobjectos em cada um dos
servidores.
4
Nas bases de dados orientadas para os objectos, este processo chama-se pointer swizzling [171]
3.2.2 Funcionamento global
Nesta subseco apresentam-se brevemente os componentes que constituem um coobjecto e descreve-se
o funcionamento de um coobjecto, explicando as interaces que se estabelecem entre os vrios compo-
nentes e entre o ncleo do sistema e um coobjecto.
Alm dos subobjectos, representantes dos subobjectos (proxies) e gestor de subobjectos, apresenta-
dos na subseco anterior, o framework de componentes DOORS inclui os seguintes componentes:
Atributos do sistema Mantm as propriedades fundamentais do coobjecto/subobjecto, as quais permi-
tem ao sistema manipul-lo. A implementao deste componente comum a todos os coobjec-
tos/subobjectos.
Atributos Mantm um conjunto de propriedades adicionais do coobjecto, as quais podem ser denidas
de forma especca para cada coobjecto.
Registo Armazena as operaes executadas (submetidas) pelos utilizadores.
Reconciliao/controlo de concorrncia Controla a execuo das operaes armazenadas no registo.
No servidor, este componente responsvel por garantir que as vrias rplicas de um mesmo
coobjecto evoluem de acordo com as expectativas (no necessariamente para o mesmo estado).
Awareness Controla o processamento da informao de awareness produzida durante a execuo das
operaes em algumas situaes, este componente dene a estratgia base utilizada, a qual
pode ser adaptada para cada utilizador.
Adaptao Controla o modo como so processadas as invocaes executadas nos representantes dos
subobjectos. Usando este componente possvel propagar uma invocao para execuo imediata
num servidor.
Cpsula Dene a composio de um coobjecto e controla o seu funcionamento. Adicionalmente, con-
trola a interaco de um coobjecto com o ncleo do sistema.
O ncleo do sistema interage com um coobjecto atravs da interface de sistema do coobjecto (ou
simplesmente interface do coobjecto). Esta interface, apresentada na gura 3.3, implementada pelo
componente cpsula. Para ser mais exacto, o interface do coobjecto consiste emduas interfaces distintas:
uma a ser implementada no servidor e outra no cliente.
3.2.2.1 Cpias de um coobjecto
Um coobjecto representado em memria atravs de um conjunto de (instncias de) componentes. No
prottipo do sistema DOORS, os componentes so representados por objectos do sistema Java.
//======================================================
// Atributos do sistema
//======================================================
interface CoobjectSysAttrib {
GOID coobjectCode(); // Coobjecto com cdigo necessrio para instanciar este coobjecto
String factoryName(); // Fbrica usada para criar/instanciar coobjectos
}
interface SubObjectSysAttrib {
String factoryName(); // Fbrica usada para criar/instanciar sub-objectos
}
//======================================================
// Parte comum do interface de sistema de um coobjecto
//======================================================
interface CommonSysCoobject {
void initNewID( ObjectHandle oH, MbrshipInfo site); // Inicia nova identidade
void executeOp(); // Fora a execuo das operaes (opt)
void writeObject(); // Armazena coobjecto localmente
void serialize( short type, Object info, ObjectOutputStream oos)
// Serializa coobjecto para propagao
void coobjectRemove(); // Coobjecto vai ser removido
}
//======================================================
// Cliente
//======================================================
interface ClientSysCoobject extends CommonSysCoobject {
OperationSeq checkChanges(); // Operaes executadas desde o ltimo commit
void changesCommitted(); // Indica que operaes obtidas anteriormente
// esto armazenadas estavelmente para serem propagadas
boolean enableDirty(); // Operaes associadas a mltiplas cpias existentes no cliente
void setPolluted();
boolean isDirty();
}
interface ClientCoobject {
CoobjectSysAttrib sysAttrib();
ClientSysCoobject sysInterface();
....
}
//======================================================
// Servidor
//======================================================
interface ServerSysCoobject extends CommonSysCoobject {
Object executeQueryOp( OperationSingle op); // Executa operao sincronamente (opt)
ExecLoggedOperation insertOp( OperationSeq op); // Entrega operaes recebidas dum cliente
void insertOp( LoggedOperation[] ops); // Insere operaes recebidas de outro servidor
LoggedOperation[] checkChanges( Timevector tv); // Obtm operaes no reflectidas pelo sumrio dado
void cleanupOp(); // Fora a reciclagem das oepraes desnecessrias
void flushAwarenessMsgs(); // Fora a propagao de mensagens de awareness
void mbrshipChange( MbrshipChange change); // Operaes associadas com as mudanas de vista
void preRemoveMember( int sitePos, int patPos);
void removeMember( int sitePos, int patPos, boolean forced);
boolean discardable( int sitePos);
}
interface ServerCoobject {
CoobjectSysAttrib sysAttrib();
ServerSysCoobject sysInterface();
....
}
Figura 3.3: Interface do coobjecto.
Os clientes e os servidores mantm uma cpia de cada coobjecto que replicam em memria estvel.
Para tal, o sistema mantm um conjunto de recursos (cheiros e bases de dados) associados a cada
coobjecto. O modo como o estado de um coobjecto armazenado nestes recursos pode ser redenido
por cada coobjecto (com excepo dos atributos do sistema). No prottipo do sistema DOORS, esta
gravao consiste, por omisso, na gravao do estado dos objectos que representam os componentes e
os subobjectos (cada um num cheiro diferente).
Um coobjecto sempre manipulado em memria. Assim, para manipular um coobjecto, necessrio
criar uma cpia desse coobjecto (em memria)
5
. O ncleo do sistema cria esta cpia com base nas
propriedades denidas nos atributos do sistema. Estas propriedades especicam a fbrica a usar na
criao da cpia do coobjecto e a localizao do cdigo necessrio. O estado do coobjecto obtido a
partir dos recursos associados ao coobjecto.
A cpia de um coobjecto pode ser manipulada directamente pelo ncleo do sistema ou entregue a
uma aplicao. Quando apropriado, o novo estado do coobjecto pode ser gravado nos recursos associados
ao coobjecto.
3.2.2.2 Funcionamento comum no cliente
Num cliente, uma aplicao manipula uma cpia privada de um coobjecto. Como se referiu anterior-
mente, esta cpia criada pelo ncleo do sistema e entregue aplicao para uso exclusivo.
Aps obter a cpia do coobjecto (ou simplesmente o coobjecto), a aplicao deve obter uma refern-
cia (representante) de um subobjecto base. Este representante (proxy) usado para aceder e modicar
o estado do subobjecto e permite aplicao navegar atravs dos subobjectos que constituem o estado
actual do coobjecto, obtendo referncias para outros subobjectos.
Quando uma aplicao invoca um mtodo num representante de um subobjecto, o representante
cria um objecto que codica a invocao executada, incluindo informao sobre o mtodo a executar e
os parmetros da invocao. O subobjecto alvo da invocao no necessita de estar instanciado nesse
momento. O representante do subobjecto entrega o objecto que codica a invocao executada ao com-
ponente de adaptao. Vrios mtodos esto disponveis no componente de adaptao dependendo de:
(1) o mtodo invocado ser de leitura ou escrita
6
; e (2) a invocao ter sido efectuada directamente pela
aplicao ou resultar da execuo de outro mtodo do coobjecto (note que um subobjecto pode manter
referncias para outros subobjectos e o cdigo de um mtodo denido num subobjecto pode invocar
mtodos de outros subobjectos).
O componente de adaptao processa a operao recebida do representante (proxy) do subobjecto
5
Por questes de ecincia, o sistema pode manter cpias em memria do conjunto de coobjectos mais utilizados.
6
Um mtodo de leitura no produz modicaes no estado do subobjecto e apenas usado para aceder ao estado actual do
subobjecto. Um mtodo de escrita produz modicaes no estado actual do subobjecto.
em funo do tipo de invocao executada (leitura/escrita, directa/indirecta) implementando a poltica
denida pelo componente. Para o processamento de uma operao existem vrias possibilidades. Por
exemplo, possvel propagar a operao imediatamente para ser executada num servidor (usando os
servios do ncleo do sistema). Neste caso, o resultado da invocao o resultado obtido remotamente
se este resultado incluir uma referncia (representante) de um subobjecto, esta referncia devidamente
integrada na cpia do coobjecto
7
. Para executar a operao localmente, o componente de adaptao
propaga o objecto que representa a invocao executada para a cpsula do coobjecto.
A cpsula controla a execuo local da operao. No caso de ser uma operao de leitura ou a
invocao resultar da execuo de outra operao, a execuo local consiste, na execuo do mtodo da
cpia privada do subobjecto (o resultado obtido, quando exista, devolvido como resultado da invocao
no representante do subobjecto)
8
. No caso de ser uma operao de escrita executada directamente por
uma aplicao, o processamento consiste normalmente em dois passos. Primeiro, a operao entregue
ao componente de registo. Segundo, o componente de reconciliao noticado da presena de uma
nova operao no registo em geral, no cliente, as operaes so executadas imediatamente, o que
consiste em executar o mtodo da cpia privada do subobjecto.
Para executar localmente uma operao num subobjecto, necessrio obter a cpia local do subob-
jecto para tal, usa-se o gestor de subobjectos. Se o subobjecto ainda no estiver instanciado, o gestor
de subobjectos encarrega-se de instanciar uma cpia privada.
A execuo de uma operao pode produzir informao de awareness. Esta informao criada
invocando, durante a execuo da operao, um mtodo especco da classe base do subobjecto. Este
mtodo apenas reenvia a invocao para o componente de awareness. O componente de awareness
processa esta informao de acordo com a poltica denida em geral, no cliente, esta informao
ignorada.
Para gravar as modicaes executadas, as aplicaes usam uma funo da API do sistema. Esta
funo, alm de gravar a verso provisria do estado do coobjecto na cache do cliente, extrai a sequncia
de operaes a propagar para o servidor. Esta sequncia de operaes extrada atravs de um mtodo
denido na interface de sistema do coobjecto (checkChanges), o qual se limita a obter esta informao
no componente de registo. Como se descreveu anteriormente, o componente registo mantm a sequncia
de todas as operaes de escrita executadas pela aplicao (e que foram executadas localmente).
7
Esta integrao, executada automaticamente, consiste em ajustar, no representante, a referncia para o componente de
adaptao.
8
Para situaes excepcionais, deniu-se um mecanismo que permite indicar durante a execuo de uma operao que se
pretende registar a prxima invocao executada noutro subobjecto. Deste modo, esta invocao ser propagada para todas as
rplicas em conjunto com a invocao original que levou execuo da operao que est a ser executar.
3.2.2.3 Funcionamento comum no servidor
Nos servidores, os coobjectos so manipulados em duas situaes: quando o servidor recebe operaes
de um cliente e durante as sesses de sincronizao. Para tal, o servidor cria uma cpia do coobjecto
(em memria), executa as aces necessrias e grava o novo estado em memria estvel. De seguida
descrevem-se as aces efectuadas em cada uma das situaes.
Quando o servidor recebe, de um cliente, uma sequncia de operaes, entrega essas operaes ao
coobjecto (atravs da interface de sistema do coobjecto). No coobjecto, a funo que recebe as opera-
es, implementada na cpsula, executa as seguintes aces. Primeiro, entrega a sequncia de operaes
ao componente de registo. O componente de registo atribui um identicador sequncia de operaes
e armazena-a. Adicionalmente, o sumrio das operaes
9
conhecidas, mantido no componente de atri-
butos e usado durante o funcionamento do coobjecto, actualizado. Segundo, notica o componente de
reconciliao da existncia de novas operaes este componente responsvel por executar as opera-
es armazenadas no componente de registo de acordo com a poltica denida (garantindo que as vrias
rplicas de um mesmo coobjecto evoluem da forma esperada). A execuo das operaes efectuada
de forma idntica execuo local de operaes no cliente (e pode originar a produo e tratamento de
informao de awareness ou a invocao de outras operaes de outros subobjectos estas invocaes
so processadas executando imediatamente as operaes nos subobjectos respectivos).
Durante as sesses de sincronizao os coobjectos podem ser acedidos em trs situaes: (1) para
transmitir o sumrio das operaes conhecidas e a informao sobre as operaes conhecidas noutros
servidores; (2) para enviar o conjunto de operaes desconhecidas no parceiro; (3) para receber um
conjunto de operaes desconhecidas do parceiro.
O sumrio das operaes conhecidas e a informao sobre as operaes conhecidas nos outros servi-
dores est guardada nos atributos do coobjecto. Para obter esta informao, o servidor no necessita de
criar uma cpia do coobjecto a API do sistema permite obter apenas os atributos de um coobjecto.
O conjunto de operaes que um servidor conhece, mas que o parceiro desconhece, obtido atravs
da interface do coobjecto (checkChanges). Esta funo obtm o conjunto de operaes a enviar para o
parceiro a partir do componente de registo. Nesta situao, o servidor utiliza a informao sobre o estado
do parceiro (operaes conhecidas e operaes que o parceiro sabe que os outros servidores conhecem)
para actualizar a sua informao local.
Quando um servidor recebe um conjunto de operaes de outro servidor, esse conjunto de operaes
entregue ao coobjecto atravs da interface do coobjecto (insertOp). Esta funo efectua as seguintes
operaes. Primeiro, entrega as operaes ao componente de registo, o qual as armazena. Segundo,
9
O identicador de uma operao e os sumrios de operaes usados no sistema DOORS so baseados em relgios lgicos
e vectoriais, como se detalha na seco 4.1.1.
informa o componente de reconciliao que existem novas operaes no componente de registo. Como
anteriormente, o servidor utiliza a informao sobre o estado do parceiro para actualizar a sua informao
local.
Um coobjecto pode ainda ser acedido durante os protocolos de mudana de liao (do conjunto de
servidores que replicam um volume). Durante este processo, e de forma semelhante s situaes anteri-
ores, o ncleo do sistema limita-se a executar as operaes respectivas na interface do coobjecto. Estas
operaes, implementadas na cpsula, acedem aos vrios componentes do coobjecto para executarem
as operaes respectivas (por exemplo, para determinar se um servidor pode ser removido necessrio
vericar se o componente de reconciliao j no necessita da informao sobre as operaes submetidas
nesse servidor).
3.2.2.4 Operaes denidas nos componentes
A descrio anterior omitiu a possibilidade de denir, nos vrios componentes, operaes que devam ser
processadas de forma semelhante s operaes dos subobjectos, i.e., registando a sua invocao e pro-
pagando estas invocaes para todas as rplicas. Por exemplo, a remoo de um coobjecto controlada
por uma operao denida no componente de atributos (ver detalhes na seco 6.1.3).
Esta funcionalidade implementada por pr-processamento do cdigo dos componentes. Para cada
operao que deve ser registada (e propagada para as vrias rplicas) so criados dois mtodos: um
mtodo que se limita a registar a operao (de forma idntica aos mtodos denidos num representante
de um subobjecto) e um mtodo sombra com o cdigo da operao.
Todas as outras funes denidas nos componentes so processadas como normais funes de um
objecto e afectam apenas o estado da cpia na qual so executadas. Por exemplo, a actualizao do
sumrio das operaes conhecidas localmente efectuada durante uma sesso de sincronizao apenas
tem efeito sobre a cpia local do coobjecto.
3.2.2.5 Atributos de uma operao
At ao momento descreveu-se o processamento comum das operaes denidas nos subobjectos (e nos
outros componentes de um coobjecto) cuja invocao interceptada no mbito do funcionamento de um
coobjecto. Este processamento comum pode ser modicado atravs dum conjunto de atributos que o
programador pode associar a uma operao quando dene o cdigo do subobjecto/coobjecto este c-
digo pr-processado, como se descreve na seco 3.4.1, de forma a que as operaes sejam executadas
da forma especicada. No sistema DOORS esto actualmente denidos os seguintes atributos:
Leitura Indica que a operao no modica o estado do coobjecto. Estas operaes no necessitam de
ser registadas.
Escrita Indica que a operao modica o estado do coobjecto. Estas operaes devem ser registadas e
propagadas para todas as rplicas.
Sistema As operaes de sistema so usadas no funcionamento interno do coobjecto. Estas operaes
no so reectidas no sumrio das operaes invocadas e so executadas numa rplica assim que
so recebidas.
ltimo escritor ganha Indica que, independentemente da poltica de reconciliao geral usada, apenas
deve ser executada uma invocao deste mtodo, caso no tenha sido executada anteriormente
uma invocao posterior (na ordem total denida pelos identicadores das operaes)
10
. Caso
tenha sido executada uma operao posterior, a execuo deste mtodo equivalente execuo
da operao nula (i.e., no modica o estado do coobjecto). Este atributo geralmente usado
apenas com as operaes de sistema.
Remota Indica que a operao deve ser executada imediatamente num servidor.
Sem desfazer-refazer Indica que a operao s deve ser executada uma vez, mesmo que o mecanismo
de reconciliao use tcnicas de desfazer-refazer (undo-redo) [17].
Silencioso e local Estes atributos so usados para controlar o funcionamento do mecanismo de invoca-
o cega, descrito em detalhe na seco 4.3.
Os componentes do coobjecto responsveis pelo processamento de uma invocao devem ter em
conta estes atributos.
3.3 Framework de componentes: componentes
Nesta seco detalham-se os vrios componentes do framework DOORS. Para cada um, descreve-se
a sua funcionalidade e discutem-se algumas das possveis implementaes, focando os componentes
pr-denidos no prottipo do sistema DOORS.
3.3.1 Atributos do sistema
Os atributos do sistema mantm as propriedades fundamentais para a manipulao de um coob-
jecto/subobjecto pelo ncleo do sistema. Existe um componente de atributos do sistema associado ao
coobjecto e a cada um dos subobjectos.
10
Para implementar esta propriedade, o pr-processador adiciona ao cdigo da operao: a gravao do identicador da
(ltima) invocao executada; e a vericao se a invocao a executar posterior ltima executada.
3.3. FRAMEWORK DE COMPONENTES: COMPONENTES 37
Estas propriedades incluem a identicao do coobjecto que contm o cdigo necessrio para instan-
ciar o coobjecto/subobjecto
11
(caso no pertena a um dos tipos bsicos do sistema DOORS) e o nome
da classe a usar como fbrica. Esta informao permite ao ncleo do sistema criar e manipular qualquer
tipo de coobjecto de forma uniforme.
Os atributos do sistema mantm ainda um sumrio das operaes executadas. Para os atributos do
sistema associados a um coobjecto, este valor reecte as operaes executadas em qualquer subobjecto.
Para os atributos do sistema associados a um subobjecto, este valor reecte as operaes executadas
que modicaram (directa ou indirectamente) esse subobjecto este sumrio actualizado durante a
execuo das operaes.
Adicionalmente, os atributos do sistema incluem uma lista de identicadores nicos que indicam
coobjectos e subobjectos que devem ser replicados conjuntamente durante a replicao prvia. Para um
coobjecto, esta lista inclui identicadores de coobjectos. Para um subobjecto, esta lista inclui identica-
dores de subobjectos.
Ao contrrio de todos os outros componentes de um coobjecto que podem ter uma implementao es-
pecca (desde que implementem a interface do componente), os atributos do sistema tm uma denio
xa para permitir ao sistema obter o tipo do coobjecto.
3.3.2 Atributos
O componente de atributos mantm um conjunto de propriedades do coobjecto. O sistema DOORS
fornece uma funo que permite s aplicaes aceder a este componente (e ao componente de atributos
do sistema) para leitura de forma leve, i.e., sem terem de obter uma cpia do coobjecto.
Existem dois tipos de propriedades. Primeiro, as propriedades do sistema, usadas pelo sistema DO-
ORS no seu funcionamento por exemplo, os sumrios das operaes conhecidas localmente e nos
outros servidores, a informao sobre o estado de remoo do coobjecto, etc. Segundo, as propriedades
especcas para cada tipo de coobjecto. Estas propriedades so denidas livremente pelos programa-
dores que implementam o coobjecto e devem representar caractersticas fundamentais do coobjecto, s
quais pode ser interessante aceder sem criar uma cpia do coobjecto.
Componentes pr-denidos No prottipo do sistema DOORS deniram-se dois componentes de atri-
butos base, cuja diferena reside no espao usado (O(n) e O(n
2
), com n o nmero de servidores que
replicam o coobjecto) para registar a informao relativa s operaes conhecidas nos outros servido-
res (as duas tcnicas so detalhadas na seco 6.2.2). A interface do componente de atributos dene
operaes que permitem manipular esta informao de forma uniforme.
11
O sistema DOORS dene um tipo bsico de coobjectos para manter o cdigo de outros coobjectos. As instncias deste
coobjecto so imutveis.
Os componentes de atributos base foram estendidos para incluir as operaes de manuteno da
identicao de uma rplica primria. Estes novos componentes devem ser usados sempre que se use
tcnicas de reconciliao baseadas num sequenciador.
Os atributos especcos de cada coobjecto so guardados numa tabela que associa nomes simblicos
a objectos. A operao de modicao utiliza, para cada nome simblico, uma estratgia de o ltimo
escritor ganha. Para tal, foi necessrio estender a aproximao o ltimo escritor ganha usada para
as operaes (seco 3.2.2.5). Sempre que esta funcionalidade genrica de manuteno de propriedades
especcas no seja adequada, um programador pode estender um componente base para denir uma
nova propriedade especca para o coobjecto que cria.
3.3.3 Registo
O componente de registo armazena as operaes de escrita executadas. Em geral, um coobjecto usa
diferentes registos no cliente e no servidor. No cliente, o registo limita-se a armazenar a sequncia de
operaes executadas localmente pela aplicao. No servidor, o registo armazena as operaes submeti-
das em todos os servidores.
O registo ainda responsvel por adicionar a seguinte informao para ordenar e traar as depen-
dncias entre as operaes, como se detalha na seco 4.1.1. No cliente, a cada sequncia de operaes
executadas adicionado o sumrio das operaes reectida no estado actual este sumrio permite de-
terminar exactamente as dependncias de uma operao, e detectar as operaes executadas concorren-
temente. No servidor, a cada sequncia de operaes recebida de um cliente atribudo um identicador
nico (composto pelo identicador da rplica e por uma estampilha temporal).
Componentes pr-denidos No prottipo do sistema DOORS deniram-se componentes base dife-
rentes para o servidor e para o cliente. Como explicado anteriormente, estes componentes base adicionam
s operaes informao que permite ordenar e traar as dependncias entre as operaes.
Para o servidor, criou-se um componente base que gere o conjunto de operaes recebidas em cada
servidor. Criou-se ainda um segundo componente base que gere adicionalmente as operaes ordenadas
por um sequenciador.
Para o cliente, criou-se apenas um componente base que mantm a lista das operaes executadas
pelos utilizadores. Este componente executa um algoritmo de compresso de operaes usando as pro-
priedades denidas nas mesmas (este algoritmo usa a aproximao descrita na seco 10.4.2).
3.3.4 Reconciliao
O componente de reconciliao (ou controlo de concorrncia) responsvel por executar as operaes
armazenadas no componente de registo. Em geral, um coobjecto usa diferentes componentes de recon-
ciliao no cliente e no servidor. No cliente, o componente de reconciliao apenas controla a execuo
imediata das operaes de forma a que os utilizadores possam observar o resultado esperado (provisrio)
das suas aces.
No servidor, este componente controla a execuo das operaes em cada rplica do coobjecto. Em
geral, pretende-se que as vrias cpias de um mesmo coobjecto evoluam para estados consistentes que
reictam as modicaes executadas pelos utilizadores. Como o sistema DOORS permite que vrios
utilizadores modiquem concorrentemente o mesmo coobjecto, este componente deve reconciliar os
uxos de actividade (possivelmente) divergentes executados por vrios utilizadores.
Este componente controla igualmente a execuo de blocos apenas-uma-vez (once-only) um
bloco once-only dene um bloco de instrues no cdigo de uma operao que apenas deve ser executado
uma vez, independentemente do nmero de cpias do coobjecto existentes (em caso da falha denitiva
de um servidor, a semntica exacta implementada deve ser: no mximo uma vez). Este blocos podem
ser usados para executar aces que tenham reexo no mundo exterior ao coobjecto (por exemplo, a
execuo de uma operao noutro coobjecto).
Como se discutiu na seco 2.3.2, vrias aproximaes podem ser usadas para controlar a evoluo
das vrias rplicas e garantir que as intenes dos utilizadores so respeitadas. Em geral, estas aproxima-
es baseiam-se na execuo das operaes em todas as rplicas por uma determinada ordem explorando
a informao semntica associada com os tipos de dados e com as operaes executadas (por exemplo,
vericando pr-condies e/ou explorando alternativas expressas pelos utilizadores).
Na seco 4.1 descrevem-se os componentes de reconciliao implementados no prottipo do sis-
tema DOORS e discutem-se as suas propriedades (assim como as propriedades de outras tcnicas de
reconciliao que poderiam ser tambm implementadas).
Entre os componentes implementados, podem-se referir aqueles que permitem executar as operaes
em todas as rplicas segundo uma ordem causal ou segundo uma ordem total (recorrendo a tcnicas
pessimistas ou optimistas). Tambm foi criado um componente que permite manter as intenes dos
utilizadores recorrendo transformao de operaes [159].
3.3.5 Awareness
O componente de awareness controla o processamento da informao de awareness produzida durante a
execuo das operaes. Como se discutiu na seco 2.3.4, existem duas aproximaes principais para
processar esta informao. A primeira consiste em manter esta informao com o coobjecto de forma
a que possa ser apresentada nas aplicaes. A segunda consiste em propagar esta informao para os
utilizadores. Um coobjecto deve usar a aproximao apropriada para o tipo de dados que implementa,
podendo igualmente combinar a utilizao de ambas. Os utilizadores devempoder adaptar a aproximao
usada s suas necessidades. Em particular, deve ser possvel controlar a informao recebida e o modo
de recepo.
Quando se mantm a informao de awareness com o coobjecto, esta informao deve estar dis-
ponvel no cliente para ser apresentada nas aplicaes. Assim, o componente de awareness respectivo
deve ser usado no cliente e no servidor. A informao de awareness actualizada denitivamente no
servidor, podendo ser igualmente actualizada, de forma provisria, no cliente. Um aspecto a realar
que esta informao mantida de forma independente para cada subobjecto, pelo que no cliente apenas
se mantm a informao relativa aos subobjectos replicados localmente.
Na propagao da informao de awareness, as possibilidades disponveis no cliente e no servidor
so diferentes. No cliente apenas possvel propagar a informao atravs do servio de disseminao
de eventos Deeds [45] no entanto, em geral, como a informao produzida corresponde execuo
provisria das operaes, a informao no propagada. No servidor possvel utilizar o servio de
awareness disponibilizado pelo ncleo do sistema (ver detalhes na seco 6.2.7) para propagar mensa-
gens atravs dos vrios transportes disponveis. Em geral, quando se usam tcnicas de reconciliao
optimista, a propagao das mensagens apenas executada aps determinar que a informao produzida
por uma operao corresponde ao resultado nal da sua execuo.
Componentes pr-denidos Para implementar as caractersticas anteriores, no prottipo do sistema
DOORS foram criados vrios componentes de awareness com diferentes funcionalidades.
Primeiro, um componente que mantm a informao de awareness como uma lista de mensagens.
As mensagens relativas a cada subobjecto so mantidas num subcomponente independente associado ao
subobjecto.
Segundo, um componente que propaga as mensagens de awareness. Este componente apenas en-
trega as mensagens ao servio de awareness do sistema DOORS, o qual se encarrega de as entregar ao
utilizador atravs do transporte indicado.
Terceiro, componentes auxiliares dos quais se destacam os seguintes. Um componente que per-
mite combinar dois outros componentes, sendo as mensagens entregues a ambos. Um componente que
descarta todas as mensagens e que pode ser usado quando no se pretende processar as mensagens de
awareness. Um componente que permite propagar apenas uma mensagem relativa a cada operao a
implementao consiste em propagar a mensagem num bloco once-only. Um componente que permite
propagar para outro apenas mensagens produzidas em operaes estveis. Para tal, este componente
armazena as mensagens de awareness recebidas, apenas as propagando para o outro componente quando
as mesma se tornam estveis (de acordo com o componente de reconciliao usado). Para que apenas
se propaguem mensagens produzidas na execuo nal de uma operao, sempre que uma operao
desfeita, o componente de awareness (informado pelo componente de reconciliao desse facto) descarta
as mensagens relativas a essa operao.
3.3.6 Adaptao
O componente de adaptao controla o processamento da invocao das operaes (executada num re-
presentante de um subobjecto ou numa operao denida noutro componente que deva ser registada).
Um coobjecto deve usar diferentes componentes de adaptao no cliente e no servidor.
No servidor, as invocaes processadas so geralmente resultado da execuo de outra operao (sob
controlo do componente de reconciliao). Neste caso, apenas necessrio executar imediatamente a
operao respectiva.
No cliente possvel utilizar diferentes aproximaes para processar as invocaes, de entre as quais
se destacam as seguintes. Primeiro, possvel executar localmente todas as invocaes (que no se-
jam explicitamente indicadas como de execuo remota), fazendo reectir as modicaes na cpia do
coobjecto que est a ser manipulada pela aplicao. Segundo, possvel propagar todas as invocaes
executadas para um servidor. Desta forma, acede-se directamente a uma cpia do coobjecto presente
num servidor usando uma estratgia semelhante execuo remota de procedimentos.
Terceiro, possvel combinar a execuo local com a execuo remota em funo das condies de
conectividade. Esta possibilidade coloca algumas questes relativas consistncia entre a cpia local e
remota que devem merecer ateno. Em geral, pretende-se que as aplicaes observem uma evoluo
consistente do estado do coobjecto, i.e., que o resultado de uma operao seja obtido sempre numa cpia
do coobjecto em que tenham sido executadas todas as operaes reectidas na cpia do coobjecto em que
as operaes anteriores foram executadas. Para tal, necessrio impor restries aos servidores usados
e/ou actualizar a cpia local com as novas modicaes conhecidas na rplica remota.
Componentes pr-denidos No prottipo do sistema DOORS foram criados componentes para utili-
zao no servidor e no cliente. Relativamente ao servidor, o componente de adaptao criado limita-se
a executar localmente todas as operaes. Relativamente aos componentes a utilizar no cliente foram
implementadas as estratgias bsicas descritas anteriormente, i.e., executar todas as operaes na cpia
local ou executar todas as operaes imediatamente num servidor
12
. Para executar remotamente uma
operao, o componente de adaptao usa o servio disponibilizado pelo ncleo do sistema.
12
O componente de execuo local executa imediatamente num servidor as operaes marcadas como remotas. Neste caso,
no se garante a consistncia entre os estados observados em invocaes consecutivas.
3.3.7 Cpsula
A cpsula dene a composio de um coobjecto e controla o seu funcionamento, denindo a forma como
so processadas localmente as invocaes executadas pelas aplicaes (e que o componente de adaptao
decide executar localmente). Adicionalmente, implementa as operaes denidas na interface de sistema
do coobjecto, denindo o modo como so processadas as operaes executadas pelo ncleo do sistema.
O processamento comum no cliente e no servidor foi descrito, respectivamente, nas seces 3.2.2.2
e 3.2.2.3 e limita-se a combinar a execuo de operaes denidas nos outros componentes.
Ao controlar o funcionamento de um coobjecto e denir a sua composio, a cpsula permite criar
coobjectos com diferentes composies como se ver de seguida.
Componentes pr-denidos Dois componentes cpsula foram implementados. O primeiro, a cpsula
simples, mantm uma nica verso do estado do coobjecto. Para tal, agrega um componente de cada tipo:
atributos do sistema, atributos, registo, reconciliao, awareness, adaptao e gestor de subobjectos. Este
componente permite criar um coobjecto comum.
O segundo componente cpsula, a cpsula dupla, mantm dois estados do coobjecto. Para tal, inclui
dois componentes de reconciliao, dois componentes de awareness e dois gestores de subobjectos. Os
dois gestores de subobjectos permitem manter duas verses de cada subobjecto, os quais so actualizados
de acordo com as (possivelmente) diferentes polticas de reconciliao denidas para cada um. Sempre
que existe uma nova operao no componente de registo, as funes denidas na cpsula noticam
ambos os componentes de reconciliao para executarem a operao na verso respectiva.
Usando esta cpsula possvel criar facilmente um coobjecto que mantenha uma verso provisria
e uma verso denitiva do seu estado (i.e. dos seus subobjectos) a partir de subobjectos comuns, exe-
cutando as operaes armazenadas no componente de registo por uma (mesma) ordem total optimista e
pessimista, respectivamente.
Os dois componentes de awareness permitem tratar de forma diferente a informao produzida pro-
visria e denitivamente (em geral, a informao produzida provisoriamente descartada). A cpsula
encarrega-se de garantir que as operaes so executadas de forma independente em cada uma das ver-
ses e que as operaes relativas a componentes no duplicados (por exemplo, ao componente de atri-
butos) apenas so executadas na verso denitiva. Para tal, cria, para cada verso, um coobjecto comum
virtual composto pelos elementos respectivos.
3.3.8 Gestor de subobjectos
O gestor de subobjectos controla a criao e remoo dos subobjectos contidos num coobjecto, exe-
cutando as seguintes funes. Primeiro, controla a criao das cpias em memria dos subobjectos e
mantm referncias para todos os subobjectos criados. Segundo, mantm referncias para um conjunto
de subobjectos raiz (acessveis atravs de um nome). As aplicaes navegam nos subobjectos contidos
num coobjecto a partir destes subobjectos raiz. Finalmente, controla a persistncia dos subobjectos no
servidor. Para esta funo duas tcnicas bsicas so geralmente adoptadas: a reciclagem automtica
(garbage-collection), em que um subobjecto removido quando ele se torna inacessvel a partir dos su-
bobjectos raiz; e a remoo explcita, em que um subobjecto removido pela execuo explcita de uma
operao de remoo.
Componentes pr-denidos No prottipo do sistema DOORS, implementou-se um gestor de subob-
jectos que combina a reciclagem automtica com a remoo explcita de forma simples. Periodicamente,
em cada servidor, determina-se o conjunto de subobjectos que no pode ser alcanado a partir dos su-
bobjectos raiz. Estes subobjectos so marcados como removidos (os outros so marcados como activos)
mas no so imediatamente eliminados. Assim, um subobjecto removido pode passar a activo se alguma
operao no executada no servidor tornar esse subobjecto acessvel novamente.
O processo de eliminao de um subobjecto inicia-se, em qualquer rplica, quando o sistema ne-
cessita de espao livre ou um subobjecto permanece removido durante um perodo de tempo grande
(actualmente, 30 dias). Quando uma das condies anteriores se verica submete-se a operao de eli-
minao denida no gestor de subobjectos (a qual propagada para todas as rplicas e executada de
acordo com a poltica de reconciliao denida no coobjecto). A execuo desta operao elimina o
subobjecto. Esta aproximao garante que todas as rplicas eliminam o mesmo conjunto de subobjectos.
O bom funcionamento desta estratgia baseia-se no pressuposto que, quando se emite a operao
de eliminao de um subobjecto, todas as operaes que o podem tornar acessvel j foram executadas
em todos os servidores. A provvel satisfao desta propriedade consequncia do perodo de tempo
longo que separa a deciso de eliminar um subobjecto da deteco inicial da sua inacessibilidade (e em
consequncia da impossibilidade de executar operaes que se reram a esse subobjecto). Como se re-
feriu, este perodo de tempo pode ser encurtado pela necessidade de um servidor obter espao livre. No
entanto, pressupe-se igualmente que o espao de armazenamento disponvel em cada servidor suci-
entemente grande para que a propriedade inicial seja satisfeita (o sistema de cheiros Elephant [148] usa
um pressuposto semelhante).
Quando uma operao torna acessvel um subobjecto eliminado anteriormente, o gestor de subob-
jectos pode criar uma nova cpia do subobjecto. Para tal, o programador deve especicar, quando cria o
subobjecto, o modo como esta cpia criada (de forma semelhante s cpias de substituio no meca-
nismo de invocao cega descrito na seco 4.3).
Esta implementao do gestor de subobjectos no lida com os problemas da execuo de operaes
em subobjectos no acessveis a partir de uma raiz ou mesmo de subobjectos j eliminados. Assim,
deve denir-se a soluo apropriada aplicao que se est a criar no mbito da implementao dos
subobjectos. A criao de um gestor de subobjectos que execute uma poltica pr-denida nesta situao
igualmente possvel. No entanto, este gestor de subobjectos obrigaria a que a informao mantida
sobre a possibilidade de alcanar um subobjecto fosse exacta em todos os momentos, o que no acontece
na implementao simples existente actualmente (em que esta deteco efectuada periodicamente de
forma ingnua).
3.3.9 Subobjectos
Os subobjectos mantm o estado de um coobjecto e denem as operaes para ler e modicar esse
estado. Assim, os subobjectos que compem cada coobjecto e a forma como se interligam internamente
tendem a ser diferentes para cada coobjecto.
No entanto, o tratamento das modicaes concorrentes pode ser efectuado atravs da cooperao
entre o componente de reconciliao e o cdigo das operaes denidas nos subobjectos. Por exemplo,
possvel denir um subobjecto que mantenha mltiplas verses de um elemento (opaco para o subob-
jecto). Neste caso, vrios coobjectos podem usar verses especializadas do mesmo subobjecto base.
Componentes pr-denidos No prottipo do sistema DOORS foram criados alguns subobjectos base
que podem ser especializados para utilizao em diferentes coobjectos.
Um dos subobjectos base criados permite manter informao sobre o estado de remoo do su-
bobjecto. Para tal, o subobjecto mantm uma varivel que dene o seu estado: removido ou activo.
Adicionalmente, denem-se duas operaes de modicao: remoo e restauro que colocam o estado
do subobjecto em removido e activo respectivamente. O mtodo de remoo grava, adicionalmente, a
informao de ordenao (o identicador da operao e o sumrio do estado do coobjecto aquando da
submisso da operao) associada operao que causa a sua execuo. O cdigo destas operaes
implementam conjuntamente a semntica o ltimo escritor ganha, garantindo que as vrias rplicas do
subobjecto convergem para o mesmo estado independentemente do componente de reconciliao.
Esta informao independente da informao mantida pelo gestor de subobjectos para controlar a
persistncia dos subobjectos e pode ser usada para implementar estratgias de remoo especcas para
uma dada aplicao.
Um segundo subobjecto base estende o subobjecto base anterior implementando a seguinte poltica
de resoluo de conitos modicao/remoo: sempre que um subobjecto removido modicado, ele
restaurado e adicionado ao conjunto de subobjectos raiz com um nome especial. Para tal, o subobjecto
base dene uma operao que verica se o subobjecto se encontra removido, e, caso isso acontea, exe-
cuta a operao de restauro (localmente). Todas as operaes de modicao denidas nos subobjectos
derivados deste subobjecto devem iniciar o seu cdigo invocando este mtodo. A operao de restauro,
alm de colocar o estado do subobjecto em activo, insere o subobjecto no conjunto de subobjectos raiz.
Um terceiro subobjectos base mantm um objecto (opaco) com mltiplas verses. Este subobjecto
dene duas operaes bsicas que alteram o seu estado: criar e remover uma verso. Internamente cada
verso imutvel e identicada por um identicador nico. A modicao de uma verso do objecto
implementada removendo a verso antiga e criando uma nova verso. Esta aproximao leva ine-
xistncia de conitos entre operaes executadas concorrentemente. Por exemplo, duas modicaes
concorrentes de uma mesma verso levam a uma dupla remoo da verso antiga (a segunda remoo
ignorada) e criao de duas novas verses. Este subobjecto garante que as suas vrias rplicas conver-
gempara umestado comumdesde que as operaes sejamexecutadas nos servidores respeitando a ordem
causal. Este subobjecto base pode ser especializado de forma a denir o tipo de objectos armazenados.
O quarto subobjecto base criado mantm uma lista de referncias nicas para outros subobjectos,
i.e., em cada lista de referncias no existe nenhum elemento repetido. Duas operaes bsicas foram
denidas: inserir e remover uma referncia para um subobjecto. Adicionalmente, deniu-se uma opera-
o para mover uma referncia. A execuo desta operao remove a referncia no subobjecto em que
executa e (em caso de sucesso na remoo) adiciona a referncia no mesmo ou noutro subobjecto. A
operao de remoo remove a referncia indicada (quando ela existe) independentemente da sua posi-
o na lista. A operao de insero indica a posio em que a referncia deve ser inserida. A existncia
de operaes submetidas concorrentemente pode levar a que a posio de insero de uma referncia seja
diferente da desejada, se o componente de reconciliao no executar um algoritmo de transformao de
operaes, como discutido na seco 4.1 (as operaes incluem o cdigo necessrio para suportar esse
algoritmo).
Para que as vrias rplicas de um subobjecto convirjam para o mesmo estado necessrio executar
todas as operaes pela mesma ordem em todas as rplicas. O cdigo das operaes no efectua nenhum
tratamento especial para as operaes submetidas concorrentemente. Assim, para operaes que actuam
sobre referncias diferentes, o efeito de todas as operaes reectido no estado nal do subobjecto.
Relativamente s operaes que actuamsobre uma mesma referncia, a ordemde execuo das operaes
determina o seu efeito no estado nal do subobjecto.
O subobjecto lista de referncias pode ser especializado para denir o tipo de referncias que podem
ser adicionadas.
O quinto subobjecto base implementa a interface de uma base de dados relacional SQL. Assim, este
subobjecto dene: uma operao de leitura, que permite executar interrogaes SQL; e uma operao de
escrita, que permite executar as instrues de modicao SQL. Para armazenar os dados e executar as
invocaes, este subobjecto utiliza uma base de dados gerida pelo ncleo do sistema, como um dos recur-
sos associado ao coobjecto. Este subobjecto permite a uma aplicao usar dados organizados segundo
o modelo relacional e mostra que o sistema DOORS pode funcionar como um sistema de replicao
genrico
13
.
3.3.10 Denio de um coobjecto: exemplo
Nesta seco exemplica-se a utilizao do framework de componentes atravs da descrio de um
coobjecto simples que mantm a associao entre um nome simblico, denido num espao de nomes
hierrquico semelhante ao espao de nomes de um sistema de cheiros, e um identicador nico.
O primeiro passo consiste em denir os subobjectos usados no coobjecto. Neste caso deniram-se
dois subobjectos: um subobjecto referncia, imutvel, que apenas armazena um identicador nico; e
um subobjecto directrio, que associa um nome simples com um subobjecto. A hierarquia de nomes
construda, a partir do subobjecto directrio raiz, associando nomes simples a subobjectos directrio (de
forma semelhante ao usado num sistema de cheiros).
O subobjecto directrio dene duas operaes bsicas. A primeira cria a associao entre um nome
e um subobjecto. Se, quando a operao executada, o nome j est associado a um subobjecto, criado
um novo nome (de forma determinista) e efectuada a associao entre o novo nome e o subobjecto. A
segunda operao remove o nome associado a um subobjecto. Se, quando a operao executada, no
existir, no subobjecto, nenhum nome simples associado ao subobjecto indicado, o espao de nomes
percorrido para remover a associao de qualquer nome ao subobjecto indicado. A remoo de um nome
associado a um directrio apenas efectuada se, quando a operao executada, o directrio se encontrar
vazio (i.e., no contiver nenhuma associao denida).
Usando as operaes bsicas anteriores, possvel modicar o nome associado a um subobjecto
(referncia ou directrio) removendo a associao antiga e criando uma nova associao (em caso de su-
cesso da remoo). Neste caso, no se aplicam as restries anteriores remoo de um nome associado
a um directrio.
O segundo passo consiste em denir a composio do coobjecto no cliente e no servidor. Como
estamos na presena de um coobjecto simples, ele inclui as implementaes mais simples dos vrios
componentes para o cliente.
No servidor, queremos que as vrias rplicas evoluam para um mesmo estado comum e que, em
13
Note que esta aproximao difere da usada nos protocolos que serializam a execuo concorrente de transaces num
conjunto de rplicas recorrendo a um sistema de comunicao em grupo [83, 2]. Nestes sistemas, a execuo de uma transaco
iniciada imediatamente na rplica local, podendo ser posteriormente abortada caso se verique a impossibilidade de serializar
a execuo das vrias transaces concorrente. No sistema DOORS, cada operao do subobjecto dene uma transaco, a
qual executada em todas as rplicas pela ordem denida pelo componente de reconciliao (se o componente de reconciliao
impuser uma ordem total, todas as rplicas executam a mesma sequncia de transaces).
3.4. FRAMEWORK DE COMPONENTES: IMPLEMENTAO 47
cada momento, apresentem um resultado provisrio que reicta todas as operaes conhecidas. Assim,
usa-se um componente de reconciliao que implementa uma ordem total optimista usando a tcnica de
desfazer-refazer. Como apenas queremos manter uma cpia dos dados, usamos uma cpsula simples.
Como no se pretende processar a informao de awareness, usa-se o componente de awareness que
descarta todas as mensagens produzidas. Para os outros componentes usou-se a implementao simples
do servidor. O gestor de subobjectos mantm referncia para um subobjecto directrio, tratado como a
raiz do espao de nomes.
Assumindo que no possvel gerar dois subobjectos referncia com o mesmo identicador nico,
podem surgir os seguintes conitos na manipulao concorrente deste coobjecto.
Primeiro, possvel associar dois subobjectos diferentes ao mesmo nome. Este conito solucionado
gerando um nome alternativo para um dos subobjectos. A execuo das operaes por ordem total
garante a convergncia nal de todas as rplicas (apesar de, momentaneamente, o mesmo nome poder
estar associado a diferentes subobjectos em diferentes rplicas e de, numa rplica, o nome associado a
um dado subobjecto poder mudar).
Segundo, a remoo concorrente do mesmo subobjecto por dois utilizadores leva, como esperado,
remoo de qualquer associao entre um nome e o referido subobjecto.
Terceiro, a remoo de um directrio (i.e., da associao entre um nome e um subobjecto directrio)
e a insero concorrente de uma nova associao nesse directrio tratada da seguinte forma. Se a opera-
o de insero ordenada antes da operao de remoo (na ordem total de execuo das operaes), a
operao de remoo no ter sucesso porque o directrio no est vazio quando a operao executada.
Neste caso a insero de um novo nome preservada e o directrio manter o nome anterior. Se a opera-
o de remoo ordenada antes da operao de insero, quando se executa a insero, o subobjecto j
no pode ser alcanado a partir de um subobjecto raiz. Assim, apesar de a insero poder ser executada,
o seu efeito no seria visvel porque o nome seria inserido num directrio que j no existia. Para lidar
com este problema usa-se a soluo executada pelo segundo subobjecto base descrito na seco 3.3.9:
o directrio recriado e adicionado ao conjunto de subobjectos raiz. Para tal, o subobjecto directrio
uma especializao desse subobjecto base. Quando o nome associado a um directrio removido com
sucesso, executa-se igualmente a operao de remoo denida no subobjecto base desse directrio.
3.4 Framework de componentes: implementao
No prottipo do sistema DOORS, o framework de componentes foi implementado na linguagem Java
como um conjunto de interfaces e classes.
Para cada tipo de componente, existe uma interface que dene o conjunto mnimo de mtodos a
implementar. Cada componente deve funcionar como uma caixa preta e apenas ser acedido atravs da
interface denida. Esta aproximao permite criar um novo componente de um dado tipo de forma
independente, i.e., sem conhecer a implementao dos componentes com os quais ele interage.
Em alguns componentes utilizaram-se classes base abstractas para denir a interface do componente
(em vez de interfaces Java). Esta opo tem duas vantagens. Primeiro, permite criar denies tpicas de
alguns mtodos. Segundo, permite implementar de forma denitiva os mtodos que executam funes
crticas para o sistema DOORS, como por exemplo, os mtodos que lidam com a representao dos
coobjectos e subobjectos usada no ncleo do sistema (por exemplo, os identicadores). Esta aproximao
garante que o mau funcionamento de um coobjecto no corrompe outros coobjectos.
Sempre que necessrio, um programador pode estender a interface bsica denida para um dado
componente com novos mtodos. A nova interface estendida pode ser usada, no s na criao de novos
componentes desse tipo, mas tambm na criao de outros componentes que necessitem de utilizar as
novas funcionalidades disponibilizadas pelos novos mtodos. Neste caso, um componente que requeira
as novas funcionalidades apenas pode ser composto com um componente que implemente a interface
estendida, impondo assim uma restrio nas composies possveis.
Um coobjecto denido como uma composio de componentes denidos de acordo com o fra-
mework de componentes DOORS. No prottipo do sistema DOORS, o cdigo de criao e ligao dos
vrios componentes deve ser criado pelo programador como parte do cdigo do componente cpsula.
Como se disse anteriormente, as ligaes entre os vrios componentes devem respeitar as interfaces
esperadas por cada um dos componentes.
No mbito do projecto DataBricks [36] esto-se a investigar formas alternativas de denio dos
coobjectos. Assim, recorrendo a uma linguagem de composio de componentes, o ComponentJ [153],
a composio e ligao dos vrios componentes de um coobjecto deve ser efectuada exteriormente ao
cdigo dos componentes do coobjecto. Esta linguagem deve permitir ainda vericar estaticamente a
compatibilidade das ligaes entre os vrios componentes. Finalmente, deve ser possvel criar esque-
letos (templates) de coobjectos. Um esqueleto de um coobjecto dene uma composio tpica para um
coobjecto no qual cam por denir um ou mais componentes (em geral, os subobjectos). Assim, um
programador pode criar um coobjecto, a partir dos subobjectos que pretende gerir, usando o esqueleto
com a semntica desejada. Este trabalho est, no entanto, fora do mbito desta dissertao.
3.4.1 Pr-processador
Actualmente, o prottipo do sistema DOORS inclui apenas um pr-processador para simplicar a criao
de componentes e subobjectos. Os programadores denem um componente ou um subobjecto como uma
classe na linguagem Java estendida com os seguintes elementos:
Um conjunto de qualicadores de mtodos (descritos na seco 3.2.2.5) que denem o tipo de
3.4. FRAMEWORK DE COMPONENTES: IMPLEMENTAO 49
operao criada.
Uma construo que permite associar a cada operao denida (mtodo), um conjunto de mtodos
adicionais associados por exemplo, um mtodo que desfaa a execuo da operao (a ser usado
com estratgias de reconciliao de desfazer-refazer).
Uma construo para a denio de blocos s-uma-vez (once-only).
A partir da denio de um subobjecto com o nome X, o pr-processador cria: uma interface com o
nome X que dene os mtodos do subobjecto; o subobjecto, denido como uma classe Java que imple-
menta a interface X e contm o cdigo dos mtodos; o representante do subobjecto, denido como uma
classe Java que implementa a interface X e controla a intercepo das operaes; e a fbrica do subob-
jecto, denida como uma classe Java. Para um componente, o pr-processador cria uma classe Java com
o mesmo nome e que inclui o cdigo necessrio para efectuar a intercepo das operaes (para cada
operao cria-se um mtodo com o cdigo de intercepo e um mtodo com o cdigo da operao).
O cdigo dos mtodos denidos no subobjecto modicado de forma a implementar a semntica
associada aos qualicadores usados (se algum). As denies dos mtodos associados s operaes (por
exemplo, o mtodo desfazer undo) substituem as denies criadas por omisso pelo pr-processador.
O pr-processador adiciona, ainda, o cdigo necessrio a que os blocos s-uma-vez sejam executadas
apenas uma vez (sob o controlo do componente de reconciliao).
As classes geradas pelo pr-processador so classes Java normalizado e devem ser posteriormente
compiladas.
3.4.2 Sumrio
O sistema DOORS disponibiliza um suporte de gesto de objectos replicados atravs de tcnicas op-
timistas. Reconhecendo que no existe uma soluo nica para satisfazer as necessidades de todas as
aplicaes, o sistema DOORS inclui um ncleo mnimo que apenas executa as tarefas comuns essen-
ciais para a gesto de dados partilhados. As solues especcas, necessrias para cada aplicao, so
executadas pelos coobjectos denidos em cada aplicao.
Neste contexto, a criao de novas aplicaes simplicada pela existncia dos seguintes elementos.
Primeiro, o framework de componentes DOORS permite estruturar uma soluo de gesto de dados num
conjunto de problemas bem identicados. Segundo, os componentes pr-denidos permitem reutilizar
um conjunto de solues de gesto de dados. Alm dos componentes existentes, possvel adicionar,
ao sistema, novos componentes que implementem diferentes propriedades. Terceiro, o pr-processador
cria automaticamente o cdigo necessrio intercepo das operaes (criando os representantes dos
subobjectos e transformando a denio dos outros componentes) e criao de subobjectos e coobjectos
(criando as fbricas necessrias).
Captulo 4
Descrio das funcionalidades principais
do sistema DOORS
No captulo anterior apresentou-se o sistema DOORS, detalhando o framework de componente denido.
Neste captulo detalham-se algumas das funcionalidade principais do sistema DOORS, incluindo uma
discusso sobre reconciliao no mbito do sistema DOORS, o modelo de replicao parcial denido, o
mecanismo de invocao cega e o modelo de integrao de sesses sncronas no mbito de uma activi-
dade tipicamente assncrona.
4.1 Reconciliao
O mecanismo de reconciliao responsvel por garantir que a evoluo das vrias rplicas respeita as
propriedades desejadas. O componente de reconciliao/controlo de concorrncia desempenha um papel
fundamental neste processo, porque decide a ordem de execuo das operaes, a qual determina, em
grande parte, as propriedades da evoluo do coobjecto.
No entanto, deve realar-se que a ordem necessria para alcanar um dado conjunto de propriedades
depende das operaes denidas no coobjecto. Adicionalmente, algumas estratgias de reconciliao so
implementadas por outros componentes do coobjecto e no esto directamente relacionadas com a ordem
de execuo das operaes. Por exemplo, o subobjecto com mltiplas verses descrito na seco 3.3.9
funciona correctamente desde que a ordem de execuo das operaes respeite a ordem causal.
Algumas das propriedades possveis na evoluo de um coobjecto so as seguintes:
Equivalncia nal A equivalncia nal consiste na igualdade
1
do estado das vrias rplicas de um co-
1
A igualdade do estado de duas rplicas de um coobjecto denida no contexto do tipo de dados que representam, i.e.,
duas rplicas so idnticas se representam exactamente o mesmo valor do tipo de dados, no sendo necessria a igualdade da
representao interna. Por exemplo, um conjunto representado atravs dos elementos contidos num vector igual a outro se o
51
52 CAPTULO 4. DESCRIO DAS FUNCIONALIDADES PRINCIPAIS DO SISTEMA DOORS
objecto aps a execuo do mesmo conjunto de operaes. Embora seja uma propriedade desejada
na maioria das situaes, pode no ser necessria em alguns coobjectos.
Rplica principal No conjunto de rplicas de um coobjecto pode existir uma rplica principal (ou grupo
de rplicas) que mantm o seu estado ocial do coobjecto. Em geral, a rplica principal (ou grupo
de rplicas) pode determinar imediatamente o resultado da execuo de uma operao.
Evoluo optimista/pessimista A evoluo de um coobjecto optimista quando todas as operaes
conhecidas numa rplica so executadas imediatamente. Neste caso, o estado de uma rplica
deve ser considerado provisrio at se determinar que as operaes foram executadas de acordo
com a ordem desejada. Quando isto no acontece, necessrio reparar a execuo optimista, por
exemplo, desfazendo o efeito das operaes executadas fora de ordem e reexecutando-as na ordem
correcta. A evoluo de um coobjecto pessimista quando as operaes so executadas apenas
aps se determinar a ordem de execuo correcta. Neste caso, o estado de uma rplica pode no
reectir todas as operaes conhecidas nessa rplica.
De seguida apresentam-se as vrias estratgias de execuo de operaes usadas no sistema DOORS.
Antes, discute-se o modo como as operaes podem ser ordenadas usando a informao disponvel nas
operaes.
4.1.1 Informao de ordenao das operaes
Para decidir a ordem das operaes, o componente de reconciliao tem ao seu dispor a seguinte infor-
mao associada a cada sequncia de operaes.
Primeiro, o par (srv
view
, n_seq), em que srv
view
o identicador do servidor
2
em que a operao
recebida de um cliente e n_seq o valor do relgio lgico [94] do coobjecto nesse servidor uma
nova sequncia de operaes tem um (nmero de sequncia) n_seq superior a todos os n_seq atribudos
anteriormente nesse servidor, mas no necessariamente imediatamente superior. Este par atribudo
a cada sequncia de operaes quando ela recebida directamente do cliente num servidor. Este par
permite identicar univocamente as operaes e denir uma ordem total entre as operaes ((s
1
, n
1
)
(s
2
, n
2
) sse n
1
< n
2
(n
1
= n
2
s
1
< s
2
)).
vector contiver os mesmos elementos, independentemente da sua ordem no vector.
2
Cada servidor tem um identicador nico em cada vista, srv
view
. Aps um perodo inicial de instabilidade aquando da
entrada do servidor no grupo de replicadores de um volume, em que o identicador do servidor pode mudar entre duas vistas
instaladas consecutivamente numa rplica (sendo actualizados os identicadores usados na identicao das operaes), o
identicador do servidor permanece imutvel at este deixar de replicar o volume. Todo o processo de gesto de liao
descrito na seco 6.2.1.
4.1. RECONCILIAO 53
Segundo, um vector verso [119], v, adicionado no cliente a cada sequncia de operaes e que con-
tm um sumrio das operaes j executadas na cpia privada do coobjecto manipulada pela aplicao.
Este vector permite determinar a dependncia causal entre as operaes (a sequncia de operaes op
1
com vector verso v
1
depende causalmente da operao op
2
com identicador (s, n) sse v
1
[s] n).
Finalmente, o componente de reconciliao pode utilizar, em cada rplica, a seguinte informao
mantida no componente de atributos do coobjecto: o sumrio (vector verso) das operaes conhecidas
localmente; o sumrio (vector verso) das operaes executadas localmente; e o sumrio (vector verso
ou matriz) das operaes que se sabem ser conhecidas nas outras rplicas. Estes vectores so mantidos
nos componentes de atributos dos coobjectos e actualizados aquando da execuo local de operaes e
durante as sesses de sincronizao.
A informao descrita anteriormente mantida em todos os coobjectos. No entanto, possvel
manter informao adicional para ultrapassar algumas limitaes colocadas pela informao anterior,
como se descreve de seguida.
Uma primeira limitao consiste no facto de apenas serem registadas dependncias causais com ope-
raes j submetidas para um servidor (i.e., operaes a que j foi atribudo um par (srv
view
, n_seq)).
Assim, no se registam as dependncias entre as sucessivas modicaes a um mesmo coobjecto num
cliente desconectado. Para minorar este problema, o cliente propaga as operaes para o mesmo servidor
por ordem de execuo. Assim, se se assumir que existe uma dependncia causal entre uma operao
identicada num servidor e todas as operaes identicadas anteriormente nesse servidor, as dependn-
cias causais existentes so respeitadas.
A seguinte soluo alternativa pode ser usada. Cada sequncia de operaes identicada atravs
de um identicador nico. A cada sequncia de operaes adicionado o conjunto (ou um resumo)
dos identicadores das operaes executadas anteriormente que ainda no foram submetidas para um
servidor
3
. No caso esperado, o espao usado por esta informao em cada sequncia de operaes
reduzido porque o nmero de elementos do conjunto pequeno e possvel resumir esse conjunto
ecientemente (por exemplo, um identicador (id_clt, n_seq), com id_clt um identicador nico do
cliente e n_seq umnmero de sequncia para as operaes executadas nesse coobjecto no cliente, permite
resumir as operaes de cada cliente usando o nmero de sequncia inicial e nal). No servidor, o
componente de reconciliao deve guardar os identicadores das operaes executadas para garantir a
satisfao das dependncias causais. Esta aproximao tem o problema da diculdade de determinar
o momento em que os identicadores podem ser descartados. Assumindo que o nmero de clientes
em que so executadas modicaes limitado, uma aproximao aceitvel consiste em manter um
3
Uma aproximao semelhante proposta por Fekete et al. [50], na qual cada operao inclui o conjunto das operaes que
a devem preceder na ordem nal de execuo.
resumo das operaes executadas nos clientes por um perodo de tempo sucientemente grande. Outras
aproximaes possveis foram propostas na literatura [5].
Uma segunda limitao da informao utilizada consiste no facto de os clientes apenas poderem
propagar cada sequncia de operaes para um s servidor. Esta limitao resulta do identicador de uma
sequncia de operaes ser atribudo quando as operaes so recebidas no servidor (se uma operao
fosse propagada para dois servidores seria tomada como duas operaes diferentes). Uma soluo para
este problema consiste na atribuio de um identicador nico a cada sequncia de operaes (como
proposto anteriormente). O componente de reconciliao usa o identicador nico para determinar se a
operao j foi executada (uma aproximao semelhante usada no sistema lazy replication [93]).
Uma terceira limitao consiste na impossibilidade de executar uma operao comidenticador (s, n)
sem executar todas as operaes com identicador (s, i) : i <n. Esta limitao consequncia do sumrio
das operaes executadas ser um vector-verso. Como consequncia, a execuo de algumas operaes
numa rplica pode ser atrasada. Esta limitao pode ser ultrapassada, por exemplo, denindo o sumrio
das operaes executadas como a combinao do vector-verso com o conjunto dos identicadores das
operaes executadas no reectidas no vector-verso. No entanto, como se antev que, devido ao
modelo de funcionamento do sistema (propagao epidmica entre servidores e os clientes tendem a
contactar sempre o mesmo servidor), as situaes em que se verica algum atraso na execuo de uma
operao so diminutas, pensa-se que a complexidade adicional no compensa.
4.1.2 Sem ordem
A estratgia mais simples de execuo das operaes consiste em no impor nenhuma restrio execu-
o das operaes, as quais podem ser executadas por ordens diferentes nas vrias rplicas.
Para tal, o componente de reconciliao sem ordem executa todas as operaes imediatamente aps
a sua recepo (de um cliente ou de outro servidor). Os blocos s-uma-vez apenas so executados no
servidor emque a operao recebida do cliente. Como uma operao recebida de umcliente executada
imediatamente, garante-se que todos os blocos s-uma-vez so executados.
Neste caso, cada rplica reecte sempre todas as operaes conhecidas. O resultado nal de uma
operao propagada para um servidor obtido imediatamente. No entanto, como as operaes so exe-
cutadas por ordemdiferente nas vrias rplicas, de um modo geral, no possvel garantir que o resultado
(efeito) da execuo de uma operao idntico em todas as rplicas. Assim, caso se pretenda obter a
equivalncia nal das rplicas, este componente apenas pode ser usados quando possvel executar as
operaes por ordem diferente (por exemplo, quando todas as operaes denidas so comutativas entre
si).
4.1. RECONCILIAO 55
4.1.3 Ordem causal
Uma operao executada por ordem causal quando apenas executada aps terem sido executadas
todas as operaes conhecidas no momento da sua submisso no cliente. A ordem causal no garante
que as operaes sejam executadas pela mesma ordem em todas as rplicas. Assim, no possvel, no
caso geral, garantir que os coobjectos convergem para o mesmo estado.
O componente de reconciliao ordem causal pessimista executa imediatamente todas as operaes
conhecidas com as dependncias causais satisfeitas (e que podem ser executadas face s limitaes apre-
sentadas anteriormente). Assim, cada rplica pode no reectir todas as operaes conhecidas. Para
conhecer imediatamente o resultado de uma operao necessrio propagar a operao para um servidor
que conhea todas as operaes reectidas na cpia do cliente. O servidor a partir do qual a cpia foi
obtida satisfaz esta propriedade.
Os blocos s-uma-vez so executados no servidor que recebeu a operao do cliente. No entanto,
como as operaes podem no ser executadas imediatamente quando so recebidas, necessrio garantir
que quando um servidor removido do grupo de replicadores do volume, os blocos s-uma-vez de todas
as operaes recebidas nesse servidor so executadas.
No sistema DOORS, um servidor abandona voluntariamente o grupo de replicadores de um volume
atravs de um protocolo que estabelece com apenas outro replicador do volume, que assume o papel de
patrocinador. Durante este protocolo, apresentado na seco 6.2.1 e detalhado nos apndices A.1.4 e
A.1.8, o servidor a remover delega na rplica do servidor patrocinador a responsabilidade de executar
os blocos s-uma-vez no executados localmente. Antes de ser removido, o servidor a remover executa
ainda os blocos s-uma-vez relativos s operaes que o patrocinador j tenha executado.
Quando se processa a remoo forada de um servidor que falhou denitivamente, impossvel
determinar as operaes que esse servidor j executou. Assim, no se delega em nenhum servidor a
execuo dos blocos s-uma-vez das operaes recebidas no servidor avariado. por esta razo que a
semntica exacta de execuo destes blocos no mximo uma vez.
4.1.4 Ordem total
As operaes so executadas por ordem total quando, em todas as rplicas, so executadas pela mesma
ordem. Neste caso, se as operaes forem deterministas, garante-se que as vrias rplicas do coobjecto
convergem para o mesmo estado. De seguida, apresentam-se as vrias estratgias utilizadas para garantir
a execuo das operaes por ordem total.
4.1.4.1 Sequenciador
No conjunto de rplicas de um coobjecto designa-se uma, o sequenciador, que ca responsvel por
seriar as operaes. Para tal, por cada nova operao recebida, o sequenciador submete uma operao
especial (que ser propagada para todas as rplicas) que apenas contm o identicador da nova operao
recebida
4
. A execuo desta operao especial corresponde execuo da operao cujo identicador
ela contm. A operao especial identicada como originria no servidor 0, i.e., tem identicador
(0, n_seq).
Em todas as rplicas, o componente de reconciliao pessimista, limita-se a executar as operaes
com identicadores (0, n_seq) por ordem crescente de nmero de sequncia.
O componente de reconciliao optimista usando a tcnica desfazer-refazer executa trs passos sem-
pre que uma nova operao recebida: desfaz as operaes executadas de forma optimista; processa as
operaes com identicadores (0, n_seq); executa de forma optimista todas as outras operaes.
Em ambos os casos, possvel transferir a funo de sequenciador entre duas rplicas. Para tal, o
sequenciador submete uma operao especial que, ao ser executada, transfere a funo de sequenciador
para outro servidor.
Quando o servidor que contm o sequenciador decide abandonar o grupo de replicadores de um
volume, o sequenciador transfere essa responsabilidade para o patrocinador
5
. Quando o servidor que
contm o sequenciador removido de forma forada, a rplica do servidor que actua como patrocinador
no protocolo de remoo forada assume o papel de sequenciador.
Os blocos s-uma-vez so executados no sequenciador. Como aps seriar uma operao, o sequen-
ciador a executa imediatamente garante-se que os blocos s-uma-vez so executados uma e uma s vez.
Nesta aproximao, o sequenciador funciona como rplica principal que mantm o estado ocial do
coobjecto. Adicionalmente, o resultado de uma operao propagada para o sequenciador conhecido
imediatamente.
A execuo da ordenao total usando um sequenciador apresenta algumas limitaes. Primeiro,
por cada operao executada num cliente, o sequenciador executa uma operao adicional que dene
a ordem de execuo da primeira. Segundo, o sequenciador funciona como ponto central de falha
quando o sequenciador falha no possvel ordenar novas operaes.
4
Actualmente, este componente limita-se a seriar as operaes pela ordem pela qual elas so recebidas no servidor. No
entanto, possvel adoptar estratgias mais complexas para optimizar o nmero de operaes que podem ser executadas com
sucesso, como proposto no sistema IceCube [134] e SqlIceCube descrito no captulo 10
5
Esta transferncia executada submetendo a operao de transferncia de sequenciador quando informado da remoo
do servidor passo 1 do protocolo de remoo.
4.1. RECONCILIAO 57
4.1.4.2 Vericao de estabilidade
Aordenao total por vericao de estabilidade consiste na execuo das operaes assimque possvel
determinar que no existe nenhuma operao anterior na ordem total denida.
O componente de reconciliao por vericao de estabilidade dene a ordem total das operaes
usando o identicador atribudo no servidor: (s
1
, n
1
) (s
2
, n
2
) sse n
1
< n
2
(n
1
= n
2
s
1
< s
2
). Para
vericar a estabilidade das operaes, cada rplica usa o sumrio das operaes conhecidas. Este sumrio
actualizado durante as sesses de sincronizao epidmicas e reecte no s as operaes recebidas,
mas tambm, os nmeros de sequncia que se sabe no terem sido usados em cada uma das rplicas.
Em cada servidor, o relgio lgico usado para atribuir o nmero de sequncia a cada operao ac-
tualizado aps cada sesso de sincronizao de forma a que seja superior ao maior nmero de sequncia
de uma operao recebida. Em consequncia, o valor relativo ao prprio servidor no sumrio das opera-
es recebidas actualizado (este assunto detalhado na seco 6.2.2). Este facto garante que, se todos
as rplicas participarem em sesses de sincronizao (que incluam transitivamente todos os servidores),
todas as operaes submetidas sero dadas como estveis em todas as rplicas independentemente do
nmero de operaes recebidas em cada servidor.
Para garantir que todas as operaes so executadas quando um servidor removido, a rplica do
coobjecto nesse servidor submete uma operao a indicar qual o ltimo nmero de sequncia utilizado.
No caso da remoo forada de um servidor, a rplica do patrocinador executa essa operao quando
informada da remoo do servidor (a sincronizao do estado entre todas as rplicas garante que o
patrocinador conhece todas as operaes do servidor removido conhecidas no sistema). Em todas as
rplicas, na ordenao das operaes, consideram-se no s as rplicas activas, mas tambm todas as
rplicas removidas at serem ordenadas todas as operaes com nmero de sequncia menor ou igual ao
ltimo nmero de sequncia usado nessa rplica.
Para garantir que as operaes so ordenadas correctamente quando um novo servidor se junta ao
grupo de replicadores de um volume, apenas necessrio ter especial cuidado com o nmero de sequn-
cia que se atribui primeira operao submetida no novo servidor (deve ser maior ou igual a max +2,
com max o valor do maior nmero de sequncia que o novo servidor sabe ter sido usado em qualquer
rplica) e utilizao da informao obtida nesse servidor (por o identicador de um servidor ser inici-
almente provisrio). A necessidade destas restries, explicada no apndice A.1.3.1, apenas car clara
aps a apresentao do mecanismo que controla o conjunto de replicadores de um volume, descrito na
seco 6.2.1.
No prottipo do sistema DOORS, implementou-se um componente de reconciliao que usa tcnicas
de vericao de estabilidade com uma aproximao pessimista. Foi igualmente implementado um
componente que usa uma aproximao optimista usando a tcnica desfazer-refazer (de forma semelhante
da ordenao total usando um sequenciador).
Para garantir a execuo correcta dos blocos s-uma-vez usa-se a mesma aproximao utilizada no
componente de reconciliao ordem causal pessimista.
Quando se usam tcnicas de estabilidade, a falha denitiva de um qualquer servidor impede a orde-
nao de novas operaes. No caso de todas as falhas nos servidores serem temporrias, garante-se que
todas as operaes so nalmente ordenadas desde que todos os servidores continuem a participar em
sesses de sincronizao, mesmo que no exista nenhum momento em que todos os servidores estejam
activos.
As mltiplas rplicas de um coobjecto convergem para um estado comum passando pelos mesmos
estados intermdios. Em cada momento existe uma rplica que executou um maior nmero de operaes
(e cujo estado se pode denir como estado ocial actual do coobjecto). No entanto, apenas possvel
determinar a sua identidade comparando o estado das vrias rplicas.
4.1.4.3 Consenso/eleio/quorum
As tcnicas apresentadas anteriormente para ordenar totalmente as operaes executadas num coobjecto
apresentam algumas limitaes na tolerncia a falhas. Assim, no caso da utilizao de uma rplica
sequenciadora, a falha do sequenciador impede o progresso do sistema, i.e., a ordenao de novas men-
sagens. No caso da utilizao de tcnicas de vericao de estabilidade, a falha denitiva de um servidor
impede o progresso do sistema (at o servidor ser removido do grupo de replicadores do volume).
Para ultrapassar as limitaes anteriores possvel implementar tcnicas de ordenao por consenso.
Neste caso, o sistema pode progredir desde que exista um qualquer quorum [56, 121] de rplicas activas.
Usando tcnicas de consenso, a ordenao das operaes faz-se em rondas sucessivas. Em cada
ronda, as rplicas de um coobjecto executam um algoritmo de consenso [102] no qual decidem qual a
operao (ou conjunto de operaes) a ordenar.
Os algoritmos de consenso propostos em [70] e [82], baseados na utilizao de comunicao epi-
dmica, podem ser implementados de forma imediata no sistema DOORS. Nestes algoritmos, em cada
ronda, cada servidor deve votar em uma e uma s operao. A operao a ser executada aquela que
obtiver um quorum de votos em [70] ou a maioria dos votos em [82]. Enquanto no algoritmo [70] pos-
svel a existncia de rondas em que nenhuma operao ordenada, em [82] selecciona-se sempre uma
operao. Em ambos os algoritmos existem situaes em que a deciso apenas pode ser tomada aps
conhecer o voto de todos os servidores, o que consistente com a conhecida impossibilidade de denir
um algoritmo de consenso que termine em todas as situaes num sistema distribudo assncrono [52].
Para contornar esta impossibilidade foram propostos vrios algoritmos usando diferentes aproximaes,
entre as quais a utilizao de detectores de falhas [3, 72, 110] e aleatoriedade [15].
4.1. RECONCILIAO 59
No decurso do trabalho que conduziu a esta dissertao explorou-se a possibilidade de desenvolver e
implementar um componente de reconciliao baseado na utilizao de um algoritmo de consenso
6
. Este
componente teria como objectivo ultrapassar as limitaes na tolerncia a falhas expostas anteriormente.
No entanto, um estudo desenvolvido num ambiente de larga escala (a Internet) [9] mostra que as
falhas de comunicao limitama disponibilidade dos sistemas de quorum. Nos ambientes de larga escala,
o melhor sistema de quorum parece ser obtido limitando os servidores utilizados a uma nica rede local.
No mbito de uma rede local, a forte correlao nas falhas dos servidores (as quais so explicadas pela
dependncia de um servio de DNS comum, de uma fonte de energia comum, de um sistema distribudo
de cheiros comum, etc.) limita a melhoria de disponibilidade obtida pela utilizao de um sistema
de quorum face ao recurso a um servidor nico. Assim, como os algoritmos de consenso requerem que
exista um quorum de servidores activos, parece no ser clara a vantagem na utilizao de um componente
de reconciliao usando tcnicas de consenso para ultrapassar as limitaes na tolerncia a falhas, face
utilizao do componente de reconciliao que usa um sequenciador. Este facto, conjugado com o
elevado nmero de mensagens envolvidas num algoritmo de consenso (i.e., mensagens necessrias para
ordenar cada operao ou conjunto de operaes), levou a que no se tivesse implementado nenhum
componente de reconciliao utilizando tcnicas de consenso.
4.1.5 Transformao de operaes
A execuo pela mesma ordem em todas as rplicas de um conjunto de operaes executadas concor-
rentemente garante a equivalncia nal das vrias rplicas. No entanto, como cada operao vai ser
executada num estado do coobjecto diferente do observado aquando da execuo (submisso) original
da operao, os seus efeitos podem ser diferentes dos esperados pelo utilizador.
Para solucionar este problema foi proposto que, antes de executar uma operao numa rplica, a
operao fosse transformada para incluir os efeitos das operaes no conhecidas aquando da execuo
inicial da operao. Desta forma, as intenes do utilizador so respeitadas. Vrios algoritmos foram
propostos utilizando esta ideia [46, 159, 118, 158].
Esta aproximao tem o inconveniente de requerer a denio de uma ou vrias funes capazes de
transformar as operaes. No caso geral, denir uma funo de transformao de operaes pode ser
bastante complexo, pelo que esta tcnica tem sido utilizada quase exclusivamente no mbito dos editores
cooperativos sncronos. No entanto, os exemplos apresentados na literatura e a experincia obtida com
o sistema DOORS, parecem sugerir que esta tcnica pode ser usada facilmente nas seguintes situaes:
anular a execuo de operaes idnticas; e ajustar parmetros que contm posies absolutas.
No prottipo do sistema DOORS estendeu-se o componente de reconciliao ordem total optimista
6
No mbito deste trabalho, chegaram a ser produzidos alguns resultado relativos teoria de sistemas de quorum [127].
usando sequenciador para efectuar a transformao de operaes de acordo com o algoritmo apresentado
em [159]. Para utilizarem este componente, os utilizadores devem denir as funes de transformao
de operaes necessrias.
4.1.6 Operaes do sistema
Como se referiu anteriormente, as operaes denidas num coobjecto podem ser classicadas como ope-
raes do sistema. Estas operaes so tratadas de forma especial pelos componentes de reconciliao:
uma operao de sistema executada imediatamente aps ser recebida no servidor e no reectida no
sumrio das operaes executadas. Assim, as operaes de sistema podem ser executadas por diferentes
ordens nas vrias rplicas. O sumrio das operaes de sistema executadas mantido de forma inde-
pendente pelo componente de reconciliao de forma a garantir que cada operao de sistema apenas
executada uma vez.
4.2 Replicao secundria parcial
O mecanismo de replicao secundria parcial (ou caching parcial) permite aos clientes obter cpias
parciais dos coobjectos. Uma cpia parcial de um coobjecto consiste na parte comum do coobjecto e
num subconjunto dos subobjectos contidos no coobjecto. A parte comum do coobjecto consiste nos
componentes necessrios (cpsula, atributos do sistema, etc.) criao de uma cpia do coobjecto.
O bom funcionamento deste mecanismo baseia-se no pressuposto que um subobjecto representa uma
unidade de manipulao dos dados, sendo possvel executar uma operao num subobjecto sem que
ocorra nenhum falha na replicao. Desta forma, a diviso de um coobjecto em subobjectos simplica o
processo de replicao antecipada (pre-fetching).
A razo lgica desta aproximao consiste na seguinte observao: o programador que desenha o
coobjecto a pessoa que melhor conhece o modo como os vrios objectos interagem entre si, e quais
devem ser replicados conjuntamente. Assim, o programador pode tornar esta informao visvel ao
sistema, agrupando os objectos fortemente ligados em unidades de maior dimenso: os subobjectos.
Adicionalmente, um subobjecto pode especicar um conjunto de outros subobjectos que devem ser re-
plicados conjuntamente com esse subobjecto (atravs da lista de subobjectos relacionados mantida no
componente de atributos do sistema associado ao subobjecto).
Um cliente obtm uma cpia parcial de um coobjecto a partir de um servidor. Posteriormente, pode
actualizar a cpia parcial ou aument-la atravs da replicao de novos subobjectos. O funcionamento
do sistema de replicao secundria parcial detalhado na seco 6.3.1.
4.3. INVOCAO CEGA 61
4.3 Invocao cega
Omecanismo de invocao cega temcomo objectivo permitir que os utilizadores produzamcontribuies
teis que afectem dados no replicados localmente durante os perodos de desconexo (como se discutiu
na seco 2.3.6).
Para tal, os utilizadores podem submeter operaes sobre subobjectos que no esto presentes local-
mente, desde que possuam uma referncia (representante) para esse subobjecto. O processamento destas
invocaes efectuado de forma semelhante ao processamento normal at ao momento em que as opera-
es devem ser executadas localmente sobre a cpia privada do subobjecto. Neste momento a execuo
no efectuada e como resultado da invocao lanada uma excepo que explica a situao. No en-
tanto, como a informao sobre a invocao guardada no componente de registo, ela ser transmitida
para o servidor onde ser executada de forma semelhante s outras invocaes. Desta forma simples, os
utilizadores podem submeter modicaes sobre subobjectos dos quais no possuem uma cpia local,
como pretendido.
O modo de processamento descrito o modo normal utilizado para processar as invocaes sobre
subobjectos no replicados localmente. No entanto, possvel aos programadores especicar, para cada
mtodo, os seguintes comportamentos alternativos:
silencioso Neste modo, no so lanadas excepes como resultado de uma invocao sobre um subob-
jecto no presente localmente para mtodos que devolvam um resultado, o programador pode
especicar um valor a devolver nessa situao.
local Neste modo, as invocaes sobre subobjectos no presentes localmente falham, sem serem arma-
zenadas no componente de registo.
A aplicao, ao obter a cpia privada do coobjecto, pode igualmente especicar o comportamento
a utilizar. As opes especicadas sobrepem-se s opes denidas por omisso nos subobjectos. O
cdigo para executar estes comportamentos alternativos criado pelo pr-processador nos representantes
dos subobjectos
7
.
4.3.1 Cpias de substituio
Para permitir a uma aplicao observar o resultado de uma invocao cega que modique o estado de um
subobjecto, permite-se a criao de uma cpia de substituio desse subobjecto.
7
No caso de a aplicao especicar o modo de operao silencioso e o resultado das operaes no estiver especicado,
as operaes devolvem valores pr-denidos no prottipo do sistema DOORS, implementado em Java, so devolvidos os
valores de iniciao para o tipo considerado.
O processamento de uma invocao tratado como normalmente at ao momento em que ne-
cessrio executar a operao na cpia privada do subobjecto. Neste momento, criada uma cpia de
substituio do subobjecto e a operao executada sobre essa cpia, como seria executada normal-
mente sobe a cpia real do subobjecto. A partir da criao desta cpia, todas as invocaes seguintes so
executadas nessa cpia.
Os programadores, ao denirem os subobjectos, devem especicar se possvel criar cpias de
substituio e o modo como estas cpias so criadas em geral, a criao de uma cpia de substituio
consiste na criao de um subobjecto em que o estado inicial denido a partir dos parmetros do
construtor. O representante (proxy) do subobjecto contm o cdigo necessrio para criar a cpia de
substituio do subobjecto
8
. Os parmetros que denem o estado inicial da cpia de substituio podem
ser denidos estaticamente, aquando da denio do cdigo do subobjecto, ou dinamicamente, aquando
da criao do subobjecto neste caso, cada representante de um subobjecto obtm uma cpia destes
parmetros quando criado.
A aplicao, ao obter a cpia privada do coobjecto, pode especicar que no pretende criar cpias de
substituio esta opo sobrepe-se opo especicada na denio dos subobjectos.
4.4 Integrao de sesses sncronas
O sistema DOORS foi desenhado para suportar a partilha de dados em ambientes de trabalho cooperativo
tipicamente assncronos. Nestes ambientes, os utilizadores executam as suas contribuies concorrente-
mente sem observarem imediatamente as modicaes que os outros utilizadores esto a efectuar. Estas
modicaes so posteriormente unicadas atravs de um mecanismo de reconciliao adaptado s ca-
ractersticas dos dados manipulados.
Assim, possvel reconhecer duas caractersticas fundamentais: o desconhecimento das modica-
es produzidas pelos outros utilizadores e a (signicativa) dimenso das contribuies de cada utili-
zador. Considere-se o exemplo da edio cooperativa de um documento. Cada utilizador desconhece
as modicaes que o outro est a executar, embora, em algumas situaes, os utilizadores possam ter
conhecimento dos elementos do documento estruturado que esto a ser modicadas pelos outros utiliza-
dores este conhecimento pode ser obtido atravs da informao de awareness ou coordenao formal
ou informal associada tarefa cooperativa. Adicionalmente, quando um utilizador modica um elemento
(por exemplo, uma seco), as modicaes tendem a ser signicativas.
Num ambiente de trabalho cooperativo tipicamente assncrono podem existir momentos pontuais em
8
No cliente, a informao sobre uma invocao contm o representante no qual a invocao foi executada. Este facto
permite criar a cpia de substituio usando o cdigo denido no representante do subobjecto, apesar de ser o componente de
reconciliao que executa a operao e o gestor do subobjecto o responsvel por manter as cpias dos subobjectos.
4.4. INTEGRAO DE SESSES SNCRONAS 63
que os utilizadores pretendem realizar sesses sncronas durante as quais manipulam os dados de forma
sncrona. Por exemplo, durante a edio cooperativa, estas sesses sncronas podem ser usadas para
coordenar o trabalho e unicar mltiplas verses dos dados.
Para responder a esta necessidade, o sistema DOORS permite que os coobjectos sejam manipulados
durante sesses sncronas. Para tal, necessrio manter vrias cpias privadas de um coobjecto sincro-
namente sincronizadas. A aproximao utilizada consiste em difundir as invocaes executadas numa
sesso sncrona para todas as cpias sncronas do coobjecto um componente de adaptao especial
implementa esta funcionalidade recorrendo a um mecanismo de comunicao em grupo
9
[18].
Um utilizador pode iniciar uma sesso sncrona a partir da sua cpia privada do coobjecto. Para tal,
ele deve instalar o componente de adaptao sncrona no seu coobjecto (assim como um componente
de reconciliao adaptado s caractersticas de uma sesso sncrona)
10
. O componente de adaptao
sncrona cria um grupo para a sesso sncrona no sistema de comunicao em grupo utilizado. A partir
deste momento possvel a outros utilizadores entrarem na sesso sncrona para manipular o coobjecto.
Quando um utilizador pretende entrar numa sesso sncrona, a aplicao deve-se juntar ao grupo
associado sesso sncrona (no prottipo do sistema, apenas necessrio conhecer o nome da sesso e
o nome de um computador que participe na sesso). A cpia privada do coobjecto criada a partir do
estado actual do coobjecto na sesso sncrona o estado actual inclui todos os subobjectos instanciados
em memria e uma referncia (handle) que permite criar os subobjectos de forma coerente em todos as
rplicas sncronas (no prottipo actual, o estado inicial obtido a partir de um elemento no grupo eleito
como primrio). Esta cpia privada actualizada atravs da execuo de todas as operaes difundidas
na sesso sncrona e no reectidas no estado inicial.
Os elementos de uma sesso sncrona podemabandon-la emqualquer momento que o desejem. Adi-
cionalmente, o mecanismo de liao do subsistema de comunicao em grupo pode forar a remoo
de elementos com os quais seja impossvel comunicar (em situaes de partio do grupo, o subsistema
de comunicao em grupo apenas deve permitir que o grupo continue activo numa das parties). Em
cada momento existe sempre um elemento do grupo que designado de primrio.
As aplicaes manipulam os coobjectos da forma habitual, i.e., atravs da execuo de operaes nos
representantes dos subobjectos. As operaes de leitura so executadas localmente o componente de
adaptao propaga a invocao para execuo local. As operaes de modicao so difundidas para
9
No prottipo do sistema DOORS foi utilizado um sistema de comunicao em grupo muito simples implementado a partir
do sistema de disseminao de eventos Deeds [45], embora fosse possvel ter optado por outros sistemas de comunicao em
grupo as nicas funcionalidades bsicas utilizadas so a difuso de mensagens e o controlo da liao.
10
Esta substituio de componentes representa um cenrio limitado de recongurao dinmica, porque as possibilidades
de recongurao esto pr-determinadas e a arquitectura est desenhada para que esta substituio possa ser efectuada sem
problemas.
todos os elementos da sesso sncrona o componente de adaptao executa esta difuso atravs do
mecanismo de comunicao em grupo associado (a cada invocao associada informao que permite
traar a dependncia entre operaes executadas na sesso sncrona).
Alm de difundir as operaes para todos os elementos do grupo, o componente de adaptao sn-
crona condiciona o processamento local das operaes. Duas alternativas podem ser adoptadas.
Primeiro, o componente de adaptao pode propagar as operaes para seremprocessadas localmente
apenas aps terem sido recebidas e ordenadas pelo subsistema de comunicao em grupo. Neste caso, o
componente de adaptao induz uma estratgia pessimista para a execuo das operaes. O componente
de reconciliao usa a ordem estabelecida para executar as operaes. O componente de reconciliao
poderia executar adicionalmente um mecanismo de transformao das operaes [46] para garantir a
preservao das intenes dos utilizadores nas operaes executadas concorrentemente.
Segundo, o componente de adaptao propaga para execuo local as invocaes locais e as invoca-
es recebidas pelo subsistema de comunicao em grupo. Neste caso, o componente de reconciliao
deve executar a estratgia adequada manipulao sncrona do respectivo tipo de dados. Esta estratgia
pode ser optimista ou pessimista.
As aplicaes podem registar funes (callbacks) no componente de adaptao para serem notica-
das do processamento de uma invocao recebida de outro elemento do grupo em geral, as aplicaes
usam este mecanismo para reectir as modicaes processadas na interface grca da aplicao.
As modicaes executadas durante uma sesso sncrona apenas podem ser gravadas pelo primrio
do grupo associado sesso sncrona. Em relao evoluo global dos coobjectos, as modicaes
executadas durante uma sesso sncrona so tratadas de forma semelhante s modicaes executadas
assincronamente por um nico utilizador. Assim, a sequncia de operaes executada propagada para
os servidores, onde integrada de acordo com a poltica de reconciliao usada pelo coobjecto nos
servidores. Note-se que esta sequncia de operaes deve representar o modo como as operaes fo-
ram executadas sequencialmente na cpia privada do coobjecto e pode ser resultado do processamento
executado pelo componente de reconciliao no cliente. Por exemplo, quando se usam tcnicas de trans-
formao de operaes [46], a sequncia de operaes enviada para o servidor inclui as operaes aps
terem sido transformadas (i.e., como foram executadas na cpia privada do coobjecto).
4.4.1 Diferentes operaes para sesses sncronas e assncronas
Anteriormente descreveu-se a aproximao bsica usada no sistema DOORS para permitir a manipula-
o de coobjectos em sesses sncronas. No entanto, esta aproximao no suciente para algumas
aplicaes em que as operaes usadas durante a interaco sncrona e assncrona devem ser diferentes
(as razes subjacentes a esta diferena sero discutidas commaior detalhe na prxima subseco). Consi-
dere-se, por exemplo, a edio cooperativa de documentos. Numa sesso sncrona so usadas operaes
com reduzida granularidade por exemplo, inserir/remover um carcter. Num sesso assncrona so
usadas operaes com uma maior granularidade por exemplo, denir uma nova verso de um elemento
(seco) do documento.
Em geral, os coobjectos, ao serem desenhados para serem manipulados em interaces assncronas,
denem apenas as operaes adequadas a este tipo de interaco. Adicionalmente, as estratgias de
gesto de dados usadas nos servidores (em particular, a estratgia de reconciliao) esto especialmente
adaptadas a este tipo de operaes e podem ser inadequadas para gerir outros tipos de operaes. No
sistema DOORS, existem duas alternativas para permitir a utilizao de operaes diferentes nas sesses
sncronas e assncronas.
A primeira alternativa consiste em estender as interfaces dos subobjectos para inclurem as operaes
usadas durante a interaco sncrona. No entanto, a utilizao destas operaes com pequena granulari-
dade na evoluo global dos coobjectos pe problemas em termos da gesto das operaes [154] (devido
ao espao necessrio para as armazenar e ao elevado nmero de operaes existentes) e da estratgia de
reconciliao usada (que deve ter em conta estas novas operaes). Assim, prope-se que, antes de serem
propagadas para os servidores, as operaes executadas durante uma sesso sncrona sejam convertidas
numa pequena sequncia de operaes assncronas que produzam o mesmo efeito. Por exemplo, uma
sequncia de inseres/remoes de caracteres convertida numa operao que dene o novo estado
de uma seco. O componente de registo utilizado no cliente dene um mecanismo de compresso
de operaes que pode ser utilizado para este efeito (atravs da denio das funes de compresso
adequadas).
A segunda alternativa consiste em manipular as operaes de pequena granularidade fora do controlo
dos coobjectos. As modicaes executadas so reectidas no estado do coobjecto executando uma
sequncia de operaes que produza o mesmo efeito (de forma semelhante ao resultado da compresso
das operaes). Para claricar esta alternativa, considere-se o exemplo da edio cooperativa. Cada
membro da sesso sncrona mantm um editor que manipula uma cpia do coobjecto estas cpias so
mantidas sincronizadas como se explicou anteriormente. A edio sncrona do texto de um elemento do
documento (por exemplo, uma seco) executada numa aplicao de edio sncrona a partir do estado
actual do elemento no coobjecto (e independentemente do coobjecto). No m da edio sncrona do
elemento, o novo estado do elemento reectido no coobjecto executando a operao correspondente.
Embora esta segunda alternativa possa ser vista como uma no soluo, ela apresenta, na prtica,
algumas caractersticas interessantes. Primeiro, torna possvel a utilizao de aplicaes j existentes
especialmente desenhadas para a gesto das interaces sncronas. Segundo, permite simplicar o de-
senho dos coobjectos, denindo apenas um tipo de operaes. Terceiro, pode possibilitar uma maior
ecincia nas comunicaes, restringindo a propagao das operaes sncronas de pequena granulari-
dade aos elementos interessados nessas operaes (por exemplo, as operaes relativas edio sncrona
de um elemento de um documento estruturado apenas so propagadas para os elementos que participam
nessa edio especca). No editor de documentos multi-sncrono desenvolvido no prottipo do sistema
DOORS foi utilizada esta estratgia (ver seco 5.1).
4.4.2 Discusso
Para algumas aplicaes, a cooperao sncrona e assncrona apresentam diferenas intrnsecas que se
reectem na forma como os dados partilhados so alterados. Estas diferenas levam a que o suporte
necessrio para os dois tipos de interaco seja igualmente diferente.
Na cooperao sncrona, as contribuies executadas por um utilizador em cada passo so geral-
mente muito reduzidas (por exemplo, a insero/remoo de um carcter). Adicionalmente, as contribui-
es de cada utilizador so propagadas para os outros utilizadores (quase) imediatamente quando um
utilizador executa uma contribuio, ele tem conhecimento de todas (ou quase todas) as modicaes
executadas pelos outros utilizadores nos dados partilhados. Este facto, permite que as contribuies de
um utilizador sejam inuenciadas pelas contribuies que os outros utilizadores esto a executar. Deste
modo, os utilizadores podem coordenar facilmente as suas modicaes.
Estas propriedades permitem a utilizao de estratgias de reconciliao agressivas em que a consis-
tncia dos dados o objectivo principal a obter (mesmo emdetrimento de preservar todas as contribuies
ou garantir a preservao das intenes dos utilizadores). Quando estas tcnicas no produzem o efeito
desejado pelos utilizadores, possvel aos utilizadores solucionar imediatamente o problema (embora
estas situaes devam ser evitadas) porque eles observam (quase) de imediato o resultado da unicao
das operaes concorrentes e porque as suas contribuies so de pequena dimenso.
Na cooperao assncrona, as contribuies executadas so geralmente de grande dimenso (por
exemplo, a modicao de uma seco de um documento). Adicionalmente, os utilizadores no tm
informao precisa sobre as contribuies que os outros utilizadores esto a produzir. Desta forma,
impossvel aos utilizadores coordenar fortemente as suas contribuies.
Assim, a estratgia de reconciliao deve ser menos agressiva do que na interaco sncrona
a consistncia dos dados e a preservao das contribuies dos utilizadores so objectivos a alcanar.
A preocupao com a preservao das contribuies consequncia de, em geral, por estas serem de
dimenso signicativa, no ser aceitvel para um utilizador perder as suas contribuies ( por esta razo
que vrios sistemas que permitem a interaco assncrona criam mltiplas verses dos dados quando no
conseguem unicar as modicaes concorrentes por exemplo, o CVS [24] e o Lotus Notes [101]).
Estas propriedades levam a que, pelo menos para algumas aplicaes e ao contrrio do que muitas
vezes sugerido na literatura [154, 42], seja impossvel obter os efeitos desejados utilizando as mesmas
tcnicas de reconciliao para controlar a interaco sncrona e assncrona. Por exemplo, considera-se
que a transformao de operaes a tcnica de reconciliao mais adequada ao controlo da edio coo-
perativa sncrona de um texto [46], denido como uma sequncia de caracteres. No entanto, a utilizao
desta tcnica durante a interaco assncrona no parece capaz de produzir resultados apropriados. Um
exemplo simples demonstra as limitaes existentes. Suponha-se que dois utilizadores modicam a frase
Tu escreve um livro. O primeiro corrige o erro produzindo o resultado nal Tu escreves um livro. O
segundo corrige o erro, mudando o sujeito da frase Ele escreve um livro. Aps a reconciliao das duas
modicaes o resultado nal seria Ele escreves um livro, ou seja, um resultado que no satisfaz nem
o primeiro utilizador nem o segundo. Os problemas tendem a ser mais graves quando as modicaes
so mais signicativas, podendo levar completa incoerncia do texto nal. Na edio sncrona, este
facto no coloca problemas porque os vrios utilizadores podem coordenar fortemente as modicaes
que produzem.
Assim, embora seja possvel traar um contnuo entre os dois extremos da cooperao sncrona e
assncrona, baseado na rapidez com que as contribuies so propagadas entre os utilizadores, parece
existir um ponto a partir do qual necessrio utilizar tcnicas de gesto de dados diferentes. As observa-
es anteriores sugerem a necessidade de usar diferentes tcnicas de reconciliao/controlo de concor-
rncia e operaes com diferentes granularidades. Adicionalmente, a gesto da informao de awareness
tambm necessita de ser adaptada. Na interaco assncrona, necessrio que um utilizador possa ser
informado das modicaes que os outros utilizadores produziram no passado (e, eventualmente, das
previses de modicaes a executar no presente/futuro). Pelo contrrio, durante as sesses sncronas, a
maior parte da informao de awareness resulta da observao imediata das modicaes que os outros
utilizadores esto a produzir e de outros canais de coordenao activos (por exemplo, ferramentas de
troca interactiva de mensagens).
Asoluo adoptada no sistema DOORS permite que estas diferenas sejamtomadas emconsiderao
na integrao de sesses sncronas. Assim, durante a interaco sncrona possvel utilizar as tcnicas de
gesto de dados adequadas a esse tipo de interaco. As modicaes produzidas nas sesses sncronas
so integradas na evoluo global dos dados atravs de operaes adequadas ao tratamento assncrono
a converso entre as operaes pode ser efectuada usando uma das duas alternativas apresentadas an-
teriormente. No mbito da evoluo global dos dados, estas operaes so tratadas de forma semelhante
s modicaes executadas assincronamente por um nico utilizador e processadas de acordo com as
tcnicas de gesto de dados adequadas interaco assncrona. Na seco 5.1 apresenta-se um editor
cooperativo multi-sncrono que demonstra a utilizao da soluo do sistema DOORS.
Captulo 5
Avaliao do modelo do sistema DOORS
O objectivo do sistema DOORS suportar a criao de aplicaes cooperativas tipicamente assncro-
nas num ambiente de larga-escala. O sistema pode ser dividido em duas partes: o ncleo do sistema,
responsvel por garantir a disponibilidade dos dados; e os coobjectos, responsveis por implementar as
solues especcas relativas partilha de dados num ambiente de larga-escala.
Para fornecer uma elevada disponibilidade dos dados, o ncleo do sistema combina a replicao dos
coobjectos no servidor, a replicao secundria parcial nos clientes e o acesso aos dados usando uma
aproximao optimista. Estas tcnicas foram usadas anteriormente em diversos sistemas (por exemplo,
Bayou [161], Lotus Notes [101] e Coda [87]) para alcanar objectivos semelhantes de forma satisfatria.
Assim, os mecanismos do sistema DOORS parecem adequados para alcanar os objectivos propostos,
quando combinados com a utilizao de boas polticas de replicao prvia (pre-fectching), distribuio
e sincronizao das rplicas. Estes problemas no foram tratados no mbito desta dissertao, mas solu-
es semelhantes s propostas em [91, 103, 84] podiam ser utilizadas no sistema DOORS. No prximo
captulo detalham-se os protocolos utilizados pelo ncleo do sistema.
O mecanismo de execuo cega e (a implementao da) replicao secundria parcial representam
duas diferenas importantes relativamente aos sistemas mencionados anteriormente. A motivao para
a introduo destes mecanismos foi apresentada nas seces 2.3.6 e 2.3.5, respectivamente. As aplica-
es apresentadas nesta seco exemplicam a sua utilizao em cenrios concretos e a simplicidade da
soluo implementada no sistema DOORS.
O framework de componentes DOORS identica um conjunto de aspectos relacionados com a parti-
lha de dados em ambientes de larga-escala. Um coobjecto pode ser criado compondo uma soluo global
a partir de solues particulares para cada um dos problemas identicados. Esta aproximao, no s,
simplica a criao de novos tipos de dados, mas tambm, permite a criao de uma soluo adequada a
cada tipo de dados. Desta forma, o framework de componentes DOORS uma pea fundamental do sis-
tema e representa uma diferena marcante relativamente generalidade de sistemas de gesto de dados.
69
70 CAPTULO 5. AVALIAO DO MODELO DO SISTEMA DOORS

Sec. 1.2
....
Sec. 1.1
....
Cap 1
....
Cap 2
....
Sec. 2.1
....
outros outros
outros

Figura 5.1: Dissertao representada como um documento estruturado (outros representa uma subrvore
que foi omitida).
As aplicaes apresentadas nesta seco exemplicam a utilizao do framework de componentes.
O prottipo do sistema DOORS utiliza extensivamente os mecanismos de carregamento dinmico de
cdigo e de serializao de objectos da linguagemJava. No entanto, o modelo proposto independente da
linguagem, como o demonstra uma implementao parcial do framework de componentes na linguagem
Phyton, executada independentemente.
De seguida, descrevem-se vrias aplicaes que exemplicam a utilizao do sistema DOORS como
suporte criao de aplicaes cooperativas tipicamente assncronas.
5.1 Editor multi-sncrono de documentos
O editor multi-sncrono de documentos permite a edio de documentos estruturados. Um documento
estruturado composto por uma rvore de elementos bsicos. O contedo dos elementos bsicos e as
possveis conguraes da rvore dependem do tipo de documento denido. Por exemplo, esta disser-
tao composta por uma sequncia de captulos; cada captulo composto pelo ttulo e algum texto
inicial seguido de uma sequncia de seces; e assim sucessivamente. Os elementos bsicos contm
texto (e guras/tabelas). Esta estrutura est ilustrada na gura 5.1.
Para modicar um documento estruturado podem denir-se operaes que modiquem a sua estru-
tura e operaes que modiquem os seus elementos bsicos.
No editor criado, os documentos estruturados so representados como coobjectos. Para tal, deniu-se
o coobjecto documento estruturado base, que utilizado como esqueleto para todos os documentos
estruturados manipulados pelo editor. Este esqueleto inclui a denio dos subobjectos que mantm a
estrutura do documento e os seus elementos bsicos.
5.1. EDITOR MULTI-SNCRONO DE DOCUMENTOS 71

Sec. 1.2
....
Sec. 1.1
....
Cap 1
....
Cap 2
....
Sec. 2.1
....
outros outros
outros
lista de referncias
objecto com
mltiplas verses

Figura 5.2: Organizao de um documento estruturado em subobjectos.
5.1.1 Coobjecto documento estruturado
A informao de um documento estruturado armazenada em dois tipos de elementos, implementados
usando dois tipos de subobjectos descritos na seco 3.3.9: a lista de referncias para outros subobjectos;
e o objecto com mltiplas verses. A estrutura de um documento construda compondo listas de
referncias numa organizao em rvore. As folhas da rvore armazenam o contedo do documento em
objectos com mltiplas verses. A gura 5.2 representa esta organizao para o documento apresentado
anteriormente.
No subobjecto lista de referncias esto denidas as operaes que permitem manipular a estrutura
de um documento, adicionando um novo elemento, removendo ou movendo um elemento existente.
No subobjecto objecto com mltiplas verses esto denidas as operaes que permitem modicar o
contedo de um elemento bsico: criar nova verso, remover e modicar uma verso existente. O modo
como as operaes submetidas concorrentemente so tratadas est igualmente denido nos subobjectos
(ver seco 3.3.9).
Relativamente aos elementos bsicos, a estratgia utilizada recorre criao de verses para que
no se perca nenhuma modicao executada por um utilizador. Esta aproximao justica-se porque se
considera o contedo de umelemento bsico uma unidade semntica de dimenses considerveis. Assim,
desconhece-se o modo de unicar modicaes concorrentes
1
. Adicionalmente, pela sua dimenso, no
razovel descartar uma modicao produzida por umutilizador. Os utilizadores devemposteriormente
criar uma modicao unicadora das vrias verses.
Relativamente estrutura, a estratgia utilizada consiste em unicar todas as modicaes produzi-
das. O fundamento lgico desta estratgia consiste no pressuposto que as modicaes concorrentes
estrutura so, em geral, modicaes complementares. No caso de um documento estruturado existem
duas situaes em que este pressuposto pode no ser verdadeiro. Primeiro, quando dois utilizadores
movem um mesmo elemento neste caso, o resultado nal reecte apenas uma das operaes, mas
1
Quando exista um algoritmo que permita unicar duas verses, possvel estender este subobjecto para unicar automati-
camente as vrias verses.
nenhuma informao perdida. Segundo, quando um utilizador move um elemento que removido
concorrentemente. Neste caso, a referncia removida
2
, pelo que o subobjecto no reecte o efeito da
operao que move a referncia. Esta situao semelhante remoo da referncia de um elemento b-
sico concorrentemente com a sua modicao: a modicao perde-se porque o subobjecto removido.
Para diminuir a probabilidade destas situaes, o editor fora a remoo de um elemento em dois
passos que devem ser executados explicitamente pelos utilizadores. Num primeiro passo, o utilizador
pode pr-remover um elemento a operao de pr-remoo submetida. No segundo passo, o utili-
zador pode remover um subobjecto pr-removido a operao que remove a referncia do elemento
submetida na lista de referncias respectiva. Relativamente a subobjectos pr-removidos, o editor apenas
permite executar duas operaes: remover e restaurar.
O coobjecto documento estruturado base um coobjecto comum baseado na cpsula simples (os
componentes utilizados esto descritos na seco 3.3).
No servidor, necessrio usar um componente de reconciliao optimista que execute as operaes
por ordem total (neste caso, utiliza-se o componente baseado na vericao da estabilidade da ordem),
de forma a garantir a convergncia das vrias rplicas e permitir a observao do efeito de todas as
operaes conhecidas (ainda que de forma provisria). Relativamente aos componentes de adaptao e
registo usam-se as implementaes mais simples para o servidor.
No cliente, usam-se as implementaes mais simples para o componente de reconciliao e de re-
gisto. Na execuo normal, usa-se o componente de adaptao que executa as operaes localmente.
Como se detalha mais tarde, durante a execuo sncrona usa-se um componente de adaptao especial
(descrito na seco 4.4). Para permitir a substituio do componente de adaptao numa instncia do
coobjecto, necessrio indicar a validade da substituio numa operao denida na cpsula do coob-
jecto para tal, criou-se uma nova cpsula derivada da cpsula simples a usar no coobjecto documento
estruturado.
Relativamente informao de awareness, usa-se o componente que mantm essa informao como
uma lista das mensagens produzidas pela execuo das operaes. As operaes denidas nos subob-
jectos produzem mensagens simples indicando quais as alteraes executadas. O editor permite aos
utilizadores consultar a lista de modicaes de forma a tomarem conhecimento da evoluo do docu-
mento
3
.
Para criar um tipo de documento especco necessrio denir quais os tipos de elementos bsicos
permitidos e a sua possvel congurao.
2
Existe uma excepo no caso de se mover a referncia para outro subobjecto e essa operao ser executada primeiro.
3
Esta informao pode ser tratada pelo editor de forma diferente por exemplo, pode usar cores diferentes para representar
os elementos que foram modicados recentemente (a esta forma de apresentar a informao de awareness usual chamar-se
conscincia partilhada (shared feedback) [43]).

Figura 5.3: Edio de um documento LaTeX. As janelas da esquerda apresentam a estrutura do docu-
mento (em cima) e as verses do elemento seleccionado (em baixo). As janelas da direita apresentam o
contedo da verso seleccionada (em cima) e a janela relativa edio multi-sncrona.
Um tipo de elemento bsico criado derivando o subobjecto objecto com mltiplas verses de forma
a incluir na interface o tipo de objectos armazenado. As novas operaes denidas limitam-se a invocar
as operaes genricas denidas no subobjecto base.
Na representao do documento estruturado como uma rvore de elementos, os ns da rvore denem
a sua estrutura. Um n da rvore criado derivando o subobjecto lista de referncias de forma a incluir na
interface o tipo de elementos que podem ser adicionados lista. As operaes denidas, aps vericarem
a validade da operao no elemento da estrutura denido, invocam as operaes genricas denidas no
subobjecto base.
Por exemplo, um documento de texto genrico pode ser denido de forma muito simples recorrendo
a dois tipos de elementos. O nico tipo de elemento bsico armazena objectos que contm texto. Os ns
da rvore so listas de referncias de outros ns e/ou de instncias do nico elemento bsico denido.
Neste caso, no se impe nenhuma restrio estrutura denida pelos utilizadores.
Na gura 5.3 pode observar-se a utilizao deste documento de texto genrico para armazenar um
documento LaTeX. Neste caso, por exemplo, cada seco armazenada como uma lista de referncias
para elementos bsicos que contm o texto da seco e os textos de cada uma das subseces (esta
organizao podia ser renada denindo, por exemplo, uma nova lista para cada subseco ou dividindo
cada seco/subseco numa sequncia de pargrafos).
Aps criar os subobjectos usados no documento que se pretende criar, o novo coobjecto criado a
partir do coobjecto documento estruturado base especicando qual o subobjecto que a raiz do docu-
mento. Todos os outros componentes usados so iguais.
Para que o editor possa manipular todos os documento derivados do coobjecto documento estrutu-
rado base, deniram-se duas interfaces de introspeco que devem ser implementadas pelos subobjectos
criados. Por exemplo, a interface relativa a uma lista de referncias, indica quais os tipos de elementos
que podem ser inseridos em cada posio.
A denio de um documento estruturado como uma rvore de subobjectos permite explorar o meca-
nismo de replicao parcial de um coobjecto. Assim, cada cliente pode obter, para cada documento, uma
cpia parcial que contenha apenas os elementos da subrvore nos quais o utilizador est interessado.
Como os elementos de um documento estruturado so alcanados por navegao a partir do subob-
jecto raiz, importante que quando se obtm uma cpia de um subobjecto, se obtenha tambm a cpia de
todas as listas que constituem o seu caminho desde a raiz. A estratgia de replicao prvia (pre-fetching)
deve garantir esta propriedade.
Para auxiliar a estratgia de replicao prvia, cada subobjecto mantm a lista dos subobjectos que o
referenciam (no componente de atributos do sistema associados ao subobjecto). As operaes denidas
no subobjecto lista de referncias procedem a essa actualizao em cada rplica. A estratgia de replica-
o prvia leva a que, ao ser replicado um subobjecto, sejam igualmente replicados todos os subobjectos
que o referenciam.
Uma organizao que poderia ter sido usada em alternativa consiste em manter toda a rvore do
documento, com excepo dos elementos bsicos, num nico subobjecto. Como a estrutura apenas
contm listas de referncias, a dimenso deste subobjecto razovel. Assim, uma cpia parcial de um
documento que inclua este subobjecto permite sempre alcanar todos os elementos bsicos.
5.1.3 Invocao cega
O mecanismo de invocao cega permite aos utilizadores modicar elementos no includos na cpia
parcial de um documento estruturado. Para que se possa observar o efeito esperado das operaes exe-
cutadas usam-se cpias de substituio. A cpia de substituio de um elemento bsico no contm
nenhuma verso. A cpia de substituio de uma lista de referncias contm uma lista sem elementos.
Os utilizadores podem usar estas cpias de substituio para executar as operaes normais. Num
elemento bsico, possvel criar novas verses e modicar ou remover as verses criadas durante a
sesso de edio. Numa lista de referncias, possvel inserir uma referncia para um novo elemento e
mover ou remover uma referncia entretanto inserida.
Os elementos do documento estruturado que so cpias de substituio so mostrados aos utilizado-
res numa cor diferente. Por exemplo, na gura 5.4 pode observar-se que esses elementos so represen-

Elemento basico de substituio
]a modificado
Elemento basico de substituio
ainda no modificado
Lista de referncias de
substituio
Figura 5.4: Cpias de substituio na edio de um documento estruturado.
tados em cor vermelha na janela que apresenta a estrutura do documento. Desta forma, os utilizadores
sabem que no esto a observar uma verso completa do elemento.
5.1.4 Edio assncrona
O editor multi-sncrono permite a edio assncrona de um documento. Assim, cada utilizador pode
modicar um documento estruturado de forma independente. O coobjecto documento estruturado base
dene a estratgia de reconciliao que se executa para tratar as modicaes executadas concorrente-
mente como se descreveu, esta estratgia combina a utilizao do componente de reconciliao com
o cdigo das operaes denidas nos subobjectos.
5.1.5 Edio sncrona
O editor multi-sncrono permite, ainda, que um grupo de utilizadores participe numa sesso sncrona
para modicar um documento estruturado. Para tal, utiliza-se a estratgia detalhada na seco 4.4.
Assim, qualquer utilizador pode iniciar uma sesso sncrona para edio de um documento, usando
a sua cpia privada como estado inicial. Novos participantes podem, posteriormente, juntar-se sesso
obtendo uma cpia do coobjecto.
Para manter o estado das vrias cpias do coobjecto sincronamente sincronizadas usa-se o com-
ponente de adaptao sncrono. Como se disse, este componente usa uma aproximao pessimista na
propagao das invocaes efectuadas: apenas entrega as invocaes para execuo local aps elas te-
rem sido ordenadas pelo sistema de comunicao em grupo. Assim, para garantir a consistncia das
rplica, usa-se o componente de reconciliao simples, o qual se limita a executar as operaes assim

Modificaes do utilizador: nmp
Modificaes do utilizador: ]alm
Utilizadores
sincronos e
suas cores

Figura 5.5: Elementos de edio sncrona no editor multi-sncrono.
que elas so conhecidas
4
.
Para permitir a edio sncrona de uma verso de um elemento bsico adopta-se a alternativa de
manipular o seu contedo de forma exterior ao coobjecto (este problema foi discutido na seco 4.4.1).
Assim, cada verso modicada no mbito de uma subsesso sncrona. Quando todos os participantes
de uma subsesso concluem as suas modicaes, submete-se no elemento bsico respectivo a operao
de modicao que substitui o contedo da antiga verso pelo resultado da edio sncrona.
Na gura 5.5 pode observar-se a edio sncrona de uma verso. Para que um utilizador tenha
conscincia das modicaes produzidas por cada participante na sesso, as modicaes so marcadas
comcores diferentes. Adicionalmente, o editor apresenta a informao de quais os participantes e fornece
uma pequena ferramenta de troca interactiva de mensagens (chat) que permite a comunicao entre os
vrios utilizadores.
5.2 Agenda partilhada
Nesta seco descreve-se uma aplicao que permite manipular uma agenda partilhada por vrios utili-
zadores. Esta agenda pode ser usada para manter as reservas efectuadas para um recurso partilhado (por
exemplo, uma sala de reunies) ou como uma agenda pessoal acedida por mais do que uma pessoa (por
exemplo, o prprio e a sua secretria).
Nesta aplicao, mltiplos utilizadores podem, independentemente, solicitar a introduo de uma
4
Para garantir que as intenes dos utilizadores so respeitadas, quando se executam concorrentemente duas operaes
sobre uma mesma lista de referncias, poderia ter sido usado um componente de reconciliao que executasse um algoritmo de
transformao de operaes.
5.2. AGENDA PARTILHADA 77

Figura 5.6: Aplicao de agenda partilhado.
nova marcao. No entanto, como impossvel introduzir duas marcaes com horrios sobrepostos
necessrio denir um esquema que garanta a consistncia nal das vrias rplicas da agenda. Este
esquema deve garantir que existe um momento (to breve quanto possvel) a partir do qual o resultado
denitivo de um pedido de nova marcao conhecido. No entanto, para evitar que os utilizadores efec-
tuem pedidos de marcaes com horrios sobrepostos a marcaes com horrio ainda no conrmado, a
agenda deve incluir o resultado provisrio das marcaes no conrmadas.
Quando efectua um pedido de nova marcao um utilizador pode indicar vrios perodos de tempo
alternativos, assim reduzindo a probabilidade de ter o seu pedido recusado. Quando o resultado nal de
um pedido determinado, deve noticar-se o utilizador do mesmo (caso este o pretenda). Na gura 5.6,
observa-se o pedido de uma nova marcao, que inclui a descrio da marcao, a sequncia de uma
sequncia de perodos de tempo alternativos e o endereo para o qual o resultado denitivo deve ser
enviado (o transporte apropriado para o endereo indicado ser usado).
Para implementar esta aplicao no sistema DOORS necessrio criar o coobjecto que mantm a
agenda partilhada. A aplicao que manipula o coobjecto fornece a interface grco que permite aos
utilizadores efectuarem novos pedidos e observarem as marcaes efectuadas anteriormente.
5.2.1 Coobjecto agenda
A informao de uma agenda armazenada nos seguintes subobjectos.
Primeiro, umsubobjecto agenda semanal, que mantmas marcaes de uma semana. Este subobjecto
inclui duas operaes de modicao para inserir e remover uma marcao num dado horrio. Para que
a inteno do utilizador seja respeitada, quando uma operao de remoo executada (removendo a
marcao que o utilizador indicou e no outra marcao escalada para a mesma hora), cada marcao
tem um identicador nico.
Segundo, um subobjecto agenda global, que mantm referncias para os subobjectos anteriores, um
por cada semana que contm marcaes. Este subobjecto inclui duas operaes de modicao para
inserir e remover uma marcao num dado horrio
5
. A execuo destas operaes consiste em invocar
a operao correspondente no subobjecto agenda semanal relativo semana indicada. Em consequncia
da execuo de uma operao de insero pode ser criado um novo subobjecto agenda semanal. Em
consequncia da execuo duma operao de remoo pode ser removida a referncia para umsubobjecto
agenda semanal.
Terceiro, um subobjecto central de marcaes, sem estado interno e que dene as operaes para
inserir e remover uma marcao com mltiplos horrios alternativos. A execuo destas operaes con-
siste em invocar, sucessivamente, para cada um dos horrios alternativos indicados at que um possa ser
executado com sucesso, a operao correspondente no subobjecto agenda global. Adicionalmente, estas
operaes produzem as mensagens de noticao correspondentes ao seu resultado.
O estado inicial de uma agenda inclui dois subobjectos raiz: um subobjecto agenda global sem
nenhuma referncia e um subobjecto central de marcaes. O nico gestor de subobjectos implementado
usado para cada uma das verses
6
.
O coobjecto agenda mantm duas verses do seu estado para tal, baseado na cpsula dupla. A
verso denitiva reecte a execuo de todos os pedidos de marcao cujo resultado se encontra garan-
tido. A verso provisria reecte, adicionalmente, a execuo de todas as outras marcaes conhecidas.
A utilizao de duas verses permite utilizar subobjectos que representem uma agenda normal, i.e., sem
que cada marcao tenha associado o estado denitivo ou provisrio.
No servidor, usam-se os seguintes componentes. Para garantir a consistncia nal das vrias rplicas,
as verses denitiva e provisria so actualizadas, respectivamente, pela verso pessimista e optimista
do componente de reconciliao que executa as operaes por uma ordem total denida por uma rplica
sequenciadora. Esta aproximao, permite estabelecer a ordem de execuo denitiva de uma operao
(e consequentemente o seu resultado nal) desde que a rplica principal esteja acessvel.
Para propagar o resultado denitivo das operaes, associa-se verso denitiva a composio do
componente de awareness que propaga as mensagens produzidas para os utilizadores com o componente
5
Este subobjecto contm uma operao adicional que remove todas as marcaes de uma semana. Esta operao usada
para remover marcaes antigas.
6
Como de supor que a maior parte dos subobjectos tenham o mesmo estado em ambas as verses, uma optimizao
possvel consiste em manter em disco, para os subobjecto iguais, apenas uma verso. Uma nova implementao do gestor de
subobjectos pode fazer esta vericao de forma simples. A manuteno de apenas uma cpia em memria parece possvel
atravs da modicao do funcionamento dos representantes dos subobjectos, embora ainda seja necessrio investigar todas as
implicaes de uma aproximao desse tipo.
5.2. AGENDA PARTILHADA 79
de awareness que garante que apenas uma mensagem enviada. As mensagens produzidas na verso
provisria so descartadas pelo componente de awareness que descarta todas as mensagens recebidas.
No cliente, a verso provisria actualizada pelo componente de reconciliao que executa imedi-
atamente as operaes submetidas. A verso denitiva no modicada usa-se um componente de
reconciliao que no executa operaes. Para ambas as verses usa-se o componente de awareness que
descarta as mensagens recebidas.
Quer no cliente, quer no servidor, usa-se a implementao mais simples disponvel para o com-
ponente de adaptao. Para o componente de registo e de atributos usam-se as implementaes mais
simples que permitam usar uma rplica sequenciadora.
Oagrupamento de todas as marcaes relativas a uma semana numsubobjecto permite que a cpia parcial
de um cliente inclua apenas um pequeno subconjunto de todas as marcaes em geral, um utilizador
apenas est interessado na semana actual e (possivelmente) em algumas das semanas seguintes. Qualquer
cpia parcial deve incluir ainda o subobjecto agenda global, o qual permite aceder s agendas semanais.
Para tal, a estratgia de replicao prvia deve garantir que a agenda global est includa em qualquer
cpia parcial (para tal, o identicador do subobjecto agenda global est includo na lista de subobjectos
relacionados em todos os subobjectos agenda semanal).
Os subobjectos denidos (com excepo do subobjecto central de reservas, explicado de seguida)
surgem como elementos naturais na representao de uma agenda outros elementos poderiam ter sido
denidos, como, por exemplo, a agenda diria. Assim, a necessidade de agrupar os objectos que mantm
os dados de um coobjecto em subobjectos, para que o mecanismo de replicao secundria parcial possa
ser utilizado, no constitui problema neste caso.
5.2.3 Invocao cega
O coobjecto agenda permite a invocao cega de operaes, independentemente dos subobjectos lo-
calmente replicados. Como o subobjecto central de marcaes um subobjecto raiz, a sua referncia
est sempre disponvel em qualquer coobjecto. Assim, possvel ao utilizador submeter novos pedidos,
mesmo que os subobjectos que contm as datas referidas no estejam disponveis localmente (como
normal, o resultado de um pedido apenas conhecido denitivamente quando a operao executada
num servidor, no qual todos os subobjectos esto disponveis).
Para permitir que o utilizador observe o resultado esperado do seu pedido, usam-se cpias de subs-
tituio. Assim, o utilizador pode igualmente remover um pedido executado anteriormente durante a
manipulao da agenda. Apesar de possvel, a submisso de uma operao de remoo relativa a uma
marcao que o utilizador sabe existir na agenda problemtica na prtica, pois requer o conhecimento
do identicador nico associado marcao.
5.3 Outras aplicaes
O sistema DOORS foi ainda usado como repositrio de dados para um conjunto de outras aplicaes
(mormente efectuadas no mbito de projectos de m de licenciatura de alunos do curso de Engenha-
ria Informtica da Faculdade de Cincias e Tecnologia da Universidade Nova de Lisboa). Entre estes,
merece realce a aplicao de base de dados discogrca cooperativa [167].
Esta aplicao permite a um conjunto de utilizadores manter informao partilhada sobre referncias
discogrcas (incluindo o nome dos lbuns, nome das msicas, nome dos autores, apontadores na Inter-
net, etc.). Cada utilizador pode atribuir uma classicao a cada referncia. Adicionalmente, para cada
referncia existe um frum de discusso.
Toda a informao mantida por esta aplicao guardada em apenas um coobjecto. Este coobjecto
armazena a informao numa base de dados relacional usando o subobjecto que implementa a interface
de uma base de dados relacional. Para garantir a convergncia nal das vrias rplicas do coobjecto,
usa-se o componente de reconciliao ordem total optimista baseada num sequenciador e usando a tc-
nica desfazer-refazer. Finalmente, usa-se o componente de awareness que permite noticar activamente
os utilizadores (por exemplo, os utilizadores podem solicitar ser informados da adio de uma nova
referncia com um dado conjunto de caractersticas).
Esta aplicao exemplica a utilizao do sistema DOORS na replicao de uma base de dados
relacional (convencional). As rplicas da base de dados so distribudas por diferentes computadores e
podem ser acedidas de forma independente (por exemplo, diferentes Intranets podem conter diferentes
rplicas sincronizadas atravs de mensagens de correio electrnico). No entanto, o funcionamento dos
coobjectos garante que as vrias rplicas convergem para o mesmo estado.
Captulo 6
Ncleo do sistema DOORS
O modelo do sistema DOORS, assim como as suas principais caractersticas e modo de utilizao do
mesmo modelo para suportar a gesto de dados partilhados, foi apresentado nos captulos anteriores.
O modelo descrito suportado por um conjunto de servios implementados pelo ncleo do sistema
DOORS. Estes servios executam as tarefas comuns indispensveis ao funcionamento dos coobjectos.
Neste captulo, apresentam-se esses servios e descreve-se a implementao efectuada no prottipo do
sistema DOORS.
Na seco 6.1 descrevem-se os aspectos gerais relativos aos coobjectos, incluindo o modo como
os mesmos so identicados. As seces seguintes detalham os servios disponveis nos servidores
(seco 6.2) e nos clientes (seco 6.3).
6.1 Coobjectos
No sistema DOORS, cada coobjecto identicado univocamente atravs de um identicador global
nico, id
coob j
(id
volume
, id
local
), em que id
volume
o identicador nico do volume no qual o coobjecto
est armazenado e id
local
o identicador nico do coobjecto no volume.
Cada subobjecto identicado univocamente atravs de identicador global nico, id
subob j

(id
coob j
, id
interno
), em que id
coob
o identicador do coobjecto a que pertence e id
interno
o identicador
nico do subobjecto no coobjecto.
O sistema DOORS inclui ainda um sistema de nomes que permite aos utilizadores usarem nomes
simblicos para designar os coobjectos. Para tal, uma camada de designao, descrita na seco 6.1.6,
faz a converso entre os nomes simblicos e os identicadores internos utilizados no sistema.
81
82 CAPTULO 6. NCLEO DO SISTEMA DOORS
// L um coobjecto existente
public CoObject getCoObject( CoobjId id, int flags);
// "Grava" as modificaes efectuadas no coobjecto
public void putCoObject( CoObject proxy);
// Armazena o coobjecto dado no sistema com o nome "id"
public void putCoObject( CoObject proxy, CoobjId id);
// Remove o coobjecto "id"
public void deleteCoObject( CoobjId id);
Figura 6.1: API do sistema DOORS para manipulao dos coobjectos.
6.1.1 Criao de um coobjecto
A criao de um coobjecto efectuada da seguinte forma. Primeiro, uma aplicao cria, de forma
exterior ao sistema DOORS, uma cpia do coobjecto em memria
1
. Esta cpia composta por instncias
dos vrios componentes do coobjecto, incluindo um conjunto de subobjectos com o estado inicial do
coobjecto.
Segundo, a aplicao grava o coobjecto no sistema DOORS invocando a funo da API do sistema
respectiva (a API do sistema relativa manipulao de coobjectos apresentada na gura 6.1). Neste
momento, atribudo um identicador nico, id
coob j
, ao coobjecto que passa a ser gerido pelo sistema
DOORS.
O estado do coobjecto no momento da sua primeira gravao (incluindo todos os seus subobjectos)
representa o seu estado inicial. O estado inicial do coobjecto armazenado nos recursos disponibilizados
pelo sistema usando as funes denidas no prprio coobjecto. Quando um coobjecto inicialmente cri-
ado num cliente, o seu estado inicial propagado para o servidor, onde se cria uma rplica do coobjecto.
Esta rplica criada usando um mtodo da fbrica do coobjecto a partir do estado inicial gravado no
cliente.
A partir deste momento, todas as modicaes executadas no coobjecto so propagadas atravs de
sequncias de operaes registadas automaticamente pelo coobjecto.
6.1.2 Criao de um subobjecto
Um subobjecto sempre criado no mbito de um coobjecto. Assim, a criao de um subobjecto corres-
ponde a criar o(s) objecto(s) que representa(m) o subobjecto e a associ-lo com um coobjecto estas
operaes so executadas automaticamente pelo mtodo respectivo denido na fbrica do subobjecto.
Durante a associao de um subobjecto com um coobjecto, atribui-se ao subobjecto o seu identicador
nico e regista-se, de forma transparente, a operao de criao do subobjecto (com o seu estado ini-
cial). Esta operao, ao ser executada em cada uma das rplicas, cria a cpia inicial do subobjecto com
1
A fbrica do coobjecto, criada pelo pr-processador, inclui mtodos para executar esta operao no cliente e no servidor.
6.1. COOBJECTOS 83
o mesmo estado inicial em todas as rplicas.
Aps a sua criao, os subobjectos so modicados atravs da execuo das operaes denidas
na sua interface. Estas operaes so registadas e propagadas para todas as rplicas, como se explicou
anteriormente. As operaes de todos os subobjectos de um coobjecto so tratadas conjuntamente.
6.1.3 Remoo de um coobjecto
Um coobjecto removido executando a funo de remoo denida na API do sistema. Esta funo
limita-se a invocar a operao de remoo denida no componente de atributos do coobjecto. Assim, a
informao sobre se um coobjecto foi removido ou no mantida pelo prprio.
Quando a operao de remoo executada numa rplica, o coobjecto passa ao estado de removido
e impedido qualquer acesso por parte dos clientes. No entanto, a rplica do coobjecto no imedia-
tamente eliminada, de forma a permitir a propagao da operao de remoo para as outras rplicas.
O servidor apenas liberta os recursos relativos a um coobjecto removido depois de obter informao
da propagao da operao de remoo para todos os outros servidores. O servidor mantm, durante
um perodo de tempo longo, denido pelo administrador do sistema, para cada coobjecto eliminado, o
seu identicador e o sumrio das operaes conhecidas no momento da eliminao. Esta informao
usada, durante as sesses de sincronizao, para informar os outros servidores que o coobjecto pode ser
eliminado caso no sejam conhecidas novas operaes nesses servidores.
Se, antes de um coobjecto ser eliminado, for recebida uma operao executada concorrentemente
com a operao de remoo, a remoo interrompida e o coobjecto passa ao estado de no removido,
podendo ser acedido de forma normal. A propagao dessa operao leva a que os outros servidores
passem igualmente ao estado de no removido. Caso o coobjecto j tenha sido eliminado em algum
servidor, esse servidor obter uma nova cpia a partir de um dos outros servidores (de forma idntica
obteno de um cpia de um novo coobjecto)
2
.
6.1.4 Remoo de um subobjecto
A remoo dos subobjectos depende do gestor de subobjectos utilizado. Em geral, podem-se utilizar
tcnicas de reciclagem automtica ou remoo explcita. Este problema foi abordado na seco 3.3.8.
6.1.5 Verso dos coobjectos
Como se descreveu na seco 4.1.1, cada sequncia de operaes identicada atravs do par
(srv
view
, n_seq), em que srv
view
identica univocamente um servidor (como se detalha na seco 6.2.1) e
2
Este processo pode causar a no execuo dos blocos apenas uma vez de algumas operaes.
n_seq identica univocamente a sequncia de operaes no conjunto das sequncias de operaes recebi-
das nesse servidor. Com base nestes identicadores, cada coobjecto mantm um sumrio (vector verso)
das operaes conhecidas localmente, um sumrio (vector verso) das operaes executadas localmente,
e um sumrio (vector verso ou matriz) das operaes que se sabe serem conhecidas nas outras rplicas.
Estes sumrios so actualizados durante as sesses de sincronizao e aquando da recepo e execuo
das operaes.
O sumrio das operaes executadas localmente (conjuntamente com o identicador da vista no qual
ele vlido) chama-se verso do coobjecto.
6.1.6 Sistema de nomes
A camada de designao simblica permite s aplicaes usar nomes simblicos para se referirem aos
volumes e aos coobjectos. Assim, esta camada dene um conjunto de funes que permitem manipular
os volumes e os coobjectos usando nomes simblicos. Estas funes convertem os nomes simblicos
nos identicadores nicos usados pelo sistema e invocam as operaes respectivas na API do sistema.
O nome simblico de um coobjecto tem a seguinte forma: [//servidor][/volume :]nome, com servidor
o nome do servidor em que o nome deve ser resolvido, volume o nome do volume e nome o nome do
coobjecto que se pretende designar.
Cada volume possui um identicador nico gerado automaticamente aquando da sua criao e um
nome simblico especicado pelo utilizador. Quando se usa um nome simblico para identicar um
volume, o nome resolvido no servidor indicado. Caso o servidor no seja indicado, o nome resolvido
localmente. Ocorre um erro caso no se conhea nenhum volume com o nome indicado ou se existir
mais do que um volume com esse nome. Nestes casos, a aplicao deve usar uma funo do sistema
(listVolumeIds) para obter a lista de identicadores de volumes com um dado nome o resultado desta
operao no necessariamente completo (a execuo da operao recorre ao servio de descoberta que
se apresenta na seco 6.2.3). Os identicadores dos volumes so expostos como cadeias de caracteres
compostas pelo nome simblico e por uma representao do identicador nico. Estes identicadores
podem ser usados para designar um volume de forma nica.
Cada volume dene um espao hierrquico de nomes (semelhante ao espao de nomes denido
num sistema de cheiros), em que cada nome associado a um identicador nico de um coobjecto.
Esta associao mantida no coobjecto directrio global, idntico ao descrito na seco 3.3.10
3
Este
coobjecto tem um identicador nico bem-denido no volume (igual para todos os volumes).
Quando um coobjecto gravado pela primeira vez, a camada de designao adiciona ao directrio
3
Relativamente descrio da seco 3.3.10, este coobjecto permite a denio adicional de ligaes simblicas (symbolic
links) atravs de um subobjecto criado para o efeito.
6.2. SERVIDORES 85
global a associao entre o nome atribudo pela aplicao e o identicador nico do coobjecto. A in-
terpretao de um nome simblico efectuada obtendo, no coobjecto directrio global, o identicador
nico associado a esse nome.
Quando se executa a funo da API do sistema (denida na camada de designao) para remover
um coobjecto, remove-se adicionalmente a associao entre o nome e o identicador desse coobjecto
(submetendo a operao de remoo respectiva no directrio global). Quando um coobjecto removido
ressuscitado pela existncia de operaes concorrentes com a operao de remoo, criada uma nova
associao entre um nome pertencente a um directrio especial e o identicador nico do coobjecto. A
adio do novo nome submetida apenas no servidor que recebeu a operao de remoo do coobjecto.
Esta responsabilidade delegada (no patrocinador) no caso de o servidor cessar a replicao do volume.
6.2 Servidores
Os servidores replicam volumes de coobjectos usando uma estratgia optimista. Esta aproximao per-
mite fornecer aos clientes um elevada disponibilidade dos dados para operaes de leitura e escrita,
permitindo mascarar (algumas) falhas nos servidores e no sistema de comunicaes.
Um servidor responsvel por gerir a cpia local de cada volume, incluindo uma cpia de cada
coobjecto contido no volume replicado. Os servidores comunicam entre si para sincronizar o estado
das rplicas locais. Adicionalmente, os servidores fornecem uma interface para administrar o servidor e
aceder aos coobjectos. Assim, os utilizadores (administradores do sistema) podem criar novos volumes e
gerir o conjunto de servidores que replicam cada volume. Para tal, os utilizadores submetem as operaes
que desejam efectuar num cliente que as propaga para o(s) servidor(es) apropriado(s). Os clientes podem
ainda obter cpias de coobjectos e submeter operaes de modicao (em consequncia das aces
executadas pelos utilizadores). Nesta seco descreve-se o funcionamento do servidor, incluindo os
vrios protocolos executados no prottipo do sistema DOORS.
6.2.1 Volumes e liao
Um volume um contentor de coobjectos replicado por um grupo varivel de servidores. Um volume
criado num servidor em resultado de uma operao (createVolume) submetida por um utilizador (admi-
nistrador do sistema). Um servidor inicia ou cessa a replicao de um volume em resultado de operaes
(replicateVolume e unreplicateVolume respectivamente) submetidas pelos utilizadores. Estas operaes
levam execuo de protocolos de insero/remoo de um servidor no grupo de replicadores de um
volume. Estes protocolos so iniciados pelo servidor que inicia/cessa a replicao do volume e tm a
participao de apenas um outro servidor, que se designa de patrocinador.
De seguida, descreve-se o funcionamento do sistema de liao implementado no sistema DOORS.
Nesta descrio, indicam-se as aces a executar pelos servidores no mbito da gesto de liao de um
dado volume, sendo que a gesto da liao de cada volume executada de forma independente.
Coobjecto de liao Em cada volume, a informao sobre o grupo de servidores que replica o volume
mantida num coobjecto especial manipulado pelo sistema, o coobjecto de liao. Este coobjecto de-
ne trs operaes de modicao: insero de um novo servidor; remoo de um servidor; e eliminao
das referncias relativas a um servidor anteriormente removido.
O estado do coobjecto de liao dene, em cada momento, uma vista (view) do grupo de replica-
dores do volume que inclui: um identicador da vista; a identicao do conjunto de replicadores; e
uma funo bijectiva que atribui a cada replicador do volume um nmero inteiro, srv
view
, que o identi-
ca na vista. Este identicador (srv
view
) usado na identicao das operaes, como se explicou na
seco 4.1.1.
Como se detalha no apndice A.1.1, o funcionamento deste coobjecto garante que duas cpias que
tenham conhecimento do mesmo conjunto de operaes tm o mesmo estado (i.e., esto na mesma vista).
Adicionalmente, garante-se que o identicador da vista a identica univocamente, i.e., a cada conjunto de
operaes corresponde um e um s identicador e a cada identicador corresponde um e um s conjunto
de operaes.
Protocolo local de mudana de vista Como se referiu anteriormente, as operaes executadas em
qualquer coobjecto de um volume so identicadas com um par que inclui o identicador do servidor
na vista. Os sumrios de operaes mantidos so igualmente baseados nestes identicadores. Assim,
necessrio actualizar estes identicadores sempre que se instala uma nova vista. Para tal, deniu-se o
protocolo local de mudana de vista, detalhado no apndice A.1.2.
Este protocolo actualiza, de forma atmica, todos os coobjectos de um volume. O modo como o
coobjecto de liao actualizado leva a que apenas sejam necessrias actualizaes quando se vericam
duas ou mais inseres concorrentes (e em que aos novos servidores foram atribudos, na execuo
optimista, o mesmo identicador em diferentes cpias do mesmo volume) ou uma insero concorrente
com uma eliminao (em que o novo servidor pode reutilizar o identicador do servidor eliminado)
4
.
Combase no coobjecto de liao e no protocolo local de mudana de vista, os protocolos de insero
e remoo voluntria de um servidor no grupo so bastante simples e envolvem a comunicao apenas
entre o servidor alvo da aco e outro servidor que pertena ao grupo de replicadores do volume. Este
4
Uma aproximao alternativa consiste em utilizar identicadores globais dos servidores. Assim, no necessrio actu-
alizar os identicadores quando uma nova vista instalada, mas o espao ocupado por estes consideravelmente maior e a
implementao e comparao dos vectores verso mais complexa
6.2. SERVIDORES 87
segundo servidor designa-se por patrocinador.
Protocolo de entrada no grupo de replicadores Para um servidor iniciar a replicao de um volume
necessrio actualizar a informao relativa ao grupo de replicadores do volume e transferir uma cpia
do volume para o novo servidor.
O protocolo de entrada no grupo de replicadores, detalhado no apndice A.1.3, iniciado pelo
servidor que pretende iniciar a replicao do volume. Este servidor contacta o patrocinador informando-o
da sua inteno. O patrocinador executa a operao de insero respectiva no coobjecto de liao e
actualiza a rplica do volume usando o protocolo local de mudana de vista. Finalmente, o patrocinador
propaga para o novo servidor, no mbito de uma sesso de sincronizao epidmica, uma cpia do
volume, incluindo todos os coobjectos.
Protocolo de sada do grupo de replicadores Quando um servidor cessa voluntariamente a replicao
de um volume necessrio que no se perca nenhuma informao que se encontre apenas nesse servidor
(i.e., operaes relativas a coobjectos do volume, incluindo o coobjecto de liao, que apenas sejam
conhecidas nesse servidor). Adicionalmente, a liao do grupo de replicadores deve ser actualizada e
os recursos usados para replicar esse volume devem ser libertos.
O protocolo de sada do grupo de replicadores de um volume, detalhado no apndice A.1.4, ini-
ciado pelo servidor i que pretende cessar a replicao do volume. Este servidor coloca-se no estado de
pr-removido e no executa mais operaes relativas a esse volume. Neste momento, todos os coobjec-
tos do volume so noticados que o servidor cessar a replicao do volume
5
. O servidor i informa o
patrocinador da sua inteno, o qual notica a rplica local de todos os coobjectos do volume desse facto.
De seguida, o patrocinador estabelece uma sesso de sincronizao com o servidor i. No m da sesso
de sincronizao, o patrocinador executa a operao de remoo respectiva no coobjecto de liao e
actualiza a rplica do volume usando o protocolo local de mudana de vista. Aps executar todas as
aces relativas sesso de sincronizao, o servidor i pode libertar os recursos relativos ao volume.
Eliminao dos identicadores dos servidores removidos Como os identicadores dos servidores
nas vistas so usados na identicao das operaes, no possvel eliminar imediatamente o identi-
cador associado a um servidor removido. Este identicador apenas pode ser eliminado quando no for
necessrio no funcionamento dos coobjectos ou seja, quando as operaes executadas no servidor
removido tiverem sido propagadas e denitivamente processadas em todos os servidores.
5
Esta informao importante em algumas solues de gesto de dados, como cou patente na discusso da seco 4.1,
relativa ao componente de reconciliao.
Para garantir estas propriedades, adicionou-se ao coobjecto de liao uma operao de dissemina-
o e execuo, detalhada no apndice A.1.5. Esta operao permite executar uma aco dada como
parmetro apenas aps a rplica do volume num servidor reectir todas as operaes conhecidas num
dado conjunto de servidores no momento da submisso da operao de disseminao e execuo.
O protocolo de eliminao de um identicador, detalhado no apndice A.1.6, iniciado pelo patro-
cinador da remoo e consiste nos seguintes passos. Primeiro, o patrocinador usa a operao de disse-
minao e execuo para garantir que nos vrios servidores, apenas se inicia o processo de eliminao
do servidor aps terem sido propagadas todas as operaes de todos os coobjectos recebidas do servidor
removido. Segundo, cada servidor notica os outros quando verica que nenhum coobjecto necessita
do identicador do servidor removido. Terceiro, quando num servidor se verica que nenhum servidor
activo necessita do identicador de um servidor, submetida a operao de eliminao do identicador.
Protocolo de sada forada do grupo de replicadores Em geral, um servidor apenas cessa a repli-
cao de um volume por sua iniciativa. No entanto, existem circunstncias em que pode ser necessrio
forar a remoo de um servidor do grupo de replicadores por exemplo, porque o servidor cou
danicado e a memria estvel na qual estava armazenado o estado dos coobjectos irrecupervel.
O protocolo de sada forada do grupo de replicadores, detalhado no apndice A.1.7, usa a seguinte
aproximao. Primeiro, qualquer servidor pode sugerir a remoo de um (ou mais) servidor(es), mas
o processo apenas prosseguir se todos os outros servidores concordarem com a remoo. Segundo,
aps eleger um servidor como patrocinador da remoo, necessrio garantir que esse servidor recebe
todas as operaes conhecidas provenientes do servidor a remover. Terceiro, o servidor informa todos os
coobjectos do volume da remoo do servidor e, de seguida, executa a operao de remoo no coobjecto
de liao no mbito do protocolo local de mudana de vista.
Protocolo de sincronizao de vistas No sistema DOORS, dois servidores apenas podem comunicar
para sincronizar o estado dos coobjectos se se encontrarem na mesma vista. Assim, dois servidores, i
e j, que se encontrem em vistas diferentes devem executar previamente um protocolo de sincronizao
de vistas. Este protocolo consiste na sincronizao das operaes do coobjecto de liao conhecidas
pelos dois servidores quando cada um dos servidores recebe o conjunto de operaes enviadas pelo
parceiro efectua o protocolo local de mudana de vista. No nal do protocolo, conhecidas as mesmas
operaes relativas ao coobjecto de liao, os dois servidores encontram-se na mesma vista. Durante
a sincronizao das operaes conhecidas, cada servidor envia para o parceiro apenas as operaes que
sabe que ele no conhece usando o sumrio das operaes conhecidas no parceiro (ou falta deste
sumrio) o identicador da vista, que igualmente um sumrio das operaes de insero e remoo que
o parceiro conhece.
6.2. SERVIDORES 89
6.2.2 Sincronizao epidmica dos servidores
Os servidores sincronizam as rplicas dos coobjectos de um volume durante sesses de sincronizao
epidmica [38] estabelecidas entre pares de servidores. Durante estas sesses, os servidores propagam
entre si as operaes de modicao que conhecem (independentemente do servidor no qual foram rece-
bidas pela primeira vez). Desta forma, cada servidor recebe, para cada coobjecto, todas as modicaes
submetidas em todos os servidores, directa ou indirectamente. No sistema DOORS, considera-se que
duas rplicas de um mesmo coobjecto esto sincronizadas quando conhecem o mesmo conjunto de ope-
raes (e os sumrios das operaes conhecidas e executadas localmente e das operaes conhecidas nos
outros servidores so idnticos).
No sistema DOORS, deniram-se dois protocolos de propagao epidmica. O primeiro protocolo
bilateral e durante a sua execuo cada um dos servidores propaga as operaes que conhece para o
parceiro. O segundo protocolo unilateral e apenas um dos servidores propaga as operaes conhecidas
para o parceiro.
Protocolo de propagao epidmica bilateral O protocolo de propagao epidmica bilateral, de-
talhado no apndice A.2.2, consiste numa sequncia de passos executados assincronamente em cada
um dos passos um servidor processa as mensagens recebidas e envia mensagens para o seu parceiro. Em
cada um dos passos, e relativamente a cada um dos coobjectos a sincronizar, possvel: (1) solicitar o
envio das operaes no reectidas num sumrio; (2) enviar um conjunto de operaes e solicitar o envio
das operaes no reectidas num sumrio; (3) solicitar o envio de uma cpia do coobjecto; (4) enviar
uma cpia do coobjecto; (5) enviar a informao que o coobjecto foi eliminado.
O protocolo de sincronizao bilateral iniciado com o servidor i a pedir que o parceiro lhe envie,
para cada um dos coobjectos a sincronizar, as operaes no reectidas no sumrio das operaes co-
nhecidas em i (este processo optimizado para que no seja trocada informao relativa aos coobjectos
estveis, i.e., que no foram modicados recentemente). O protocolo continua por mais trs passos, em
que cada um dos parceiros responde aos pedidos recebidos e solicita o envio da informao necessria
sincronizao das rplicas dos coobjectos.
Protocolo de propagao epidmica unilateral No protocolo de propagao epidmica unilateral,
detalhado no apndice A.2.3, um servidor, i, envia para outro servidor, j, a informao que permite a j
sincronizar o estado de j com o estado de i (i.e., o servidor j deve car a conhecer todas as operaes
conhecidas em i). Para tal, o servidor i envia para j todas as operaes (e novos coobjectos) que, de
acordo com o sumrio das operaes conhecidos nos outros servidores, no sabe serem conhecidas em
j.
6.2.2.1 Comunicaes entre os servidores
Como se descreveu, os protocolos de sincronizao implementados no sistema DOORS so intrinseca-
mente assncronos. Assim, possvel executar esses protocolos sobre transportes sncronos e assncro-
nos. Cada servidor pode receber comunicaes num subconjunto no vazio de transportes. Para cada
volume, o coobjecto de liao mantm informao sobre os transportes implementados em cada servi-
dor.
No prottipo do sistema DOORS foram implementados os seguintes transportes. O primeiro, sn-
crono ponto-a-ponto, usando directamente o protocolo de comunicaes TCP. Neste caso, um servidor
aceita continuamente conexes de outros servidores numa porta denida para o efeito.
O segundo, assncrono ponto-a-ponto, usando correio electrnico. Neste caso, um servidor aceita
comunicaes de outros servidores atravs dum endereo de correio electrnico denido para o efeito.
O servidor verica periodicamente a existncia de novas mensagens usando o protocolo POP3.
6.2.2.2 Poltica de sincronizao
Cada volume implementa uma poltica de sincronizao prpria, que dene os momentos em que cada
sesso de sincronizao deve ser estabelecida, quais os servidores envolvidos e quais os transportes a
utilizar. O coobjecto de liao de cada volume mantm a denio da poltica de sincronizao como
umobjecto que implementa uma interface pr-denida. Esta poltica pode ser alterada pelo administrador
do sistema. Com base nesta informao, os servidores so responsveis por iniciar os protocolos de
sincronizao nos momentos adequados.
O estudo de polticas de sincronizao ptimas para diferentes conguraes est fora do mbito
desta dissertao este assunto foi abordado em vrios estudos [38, 57, 84]. No prottipo do sistema
DOORS foram pr-denidas as seguintes estratgias simples. A primeira, aleatria, na qual cada ser-
vidor selecciona aleatoriamente o parceiro entre os servidores conhecidos. A segunda, utilizando uma
congurao em forma de anel estabelecida a partir dos identicadores dos servidores. Em ambos os
casos, dene-se o momento da prxima sesso de sincronizao utilizando uma varivel aleatria de
distribuio exponencial (com tempo mdio denido pelo administrador do sistema).
Durante os perodos de mudana de vista (i.e., quando no se sabe que as operaes de entrada e sada
do grupo de replicadores foram propagadas para todos os outros servidores), existem servidores que tm
uma viso desactualizada (e temporariamente divergente entre si) do conjunto dos replicadores de um
volume. Assim, necessrio ter algum cuidado para garantir que as mudanas no grupo de replicadores
sejam propagadas para todos os servidores. Nas estratgias pr-denidas, usa-se sempre uma estratgia
aleatria com um tempo mdio entre sesses muito curto durante os perodos de mudana de vista. Este
problema discutido com maior detalhe no apndice A.2.4
6.2. SERVIDORES 91
6.2.3 Servio de descoberta e disseminao de eventos
Os servidores do sistema DOORS esto interligados atravs do sistema de disseminao de eventos
Deeds [45]. O sistema Deeds fornece um servio de disseminao de eventos baseado em canais. Os
clientes do servio podem criar novos canais, subscrever canais j existentes e enviar eventos para um
canal. Um evento enviado para um canal propagado para os clientes que subscrevem o canal. As
garantias de entrega de um evento a um cliente de um canal dependem da semntica do canal.
Todos os servidores do sistema DOORS subscrevem um canal de disseminao de eventos usado
para descobrir quais os servidores que replicam um dado volume. Este canal de disseminao propaga
os eventos para todos os servidores com a semntica de propagao melhor esforo. Quando um
cliente necessita de conhecer um servidor que replica umvolume at ao momento desconhecido, o cliente
submete um evento de descoberta neste canal.
Para cada volume criado um canal de disseminao usado para propagar de forma expedita as
novas operaes submetidas no mbito de um volume, como se detalha no apndice A.2.5. Quando uma
operao recebida e identicada num servidor, ela imediatamente propagada para os outros servidores
atravs deste canal de disseminao. Este canal usa uma semntica de propagao "melhor esforo", pelo
que no garante a entrega da operao a todos os servidores que subscrevem o canal. A subscrio do
canal por parte de um servidor que replica um volume opcional a sincronizao epidmica, descrita
na seco 6.2.2, o mecanismo base que garante a sincronizao das vrias rplicas.
6.2.4 Interaco com os clientes
Os servidores fornecem uma interface aos clientes que permite administrar o servidor e aceder aos co-
objectos ver gura 6.2. As operaes de administrao do servidor permitem criar novos volumes e
iniciar/terminar a replicao de um volume num dado servidor. A execuo destas operaes leva exe-
cuo dos protocolos descritos na seco 6.2.1. Adicionalmente, possvel forar a execuo de sesses
de sincronizao (completas ou parciais) entre dois servidores (relativas a um dado volume). A execuo
destas operaes leva execuo dos protocolos descritos na seco 6.2.2.
As operaes denidas para manipular coobjectos permitem aos clientes aceder ao estado actual dos
coobjectos e submeter modicaes. De seguida descrevem-se as operaes denidas para manipular
coobjectos e o modo como elas so implementadas.
getCoObject Permite, ao cliente, obter uma cpia de um coobjecto e de um conjunto de subobjectos
pertencentes a um mesmo coobjecto. No caso de o cliente j possuir uma cpia do coobjecto
(indicando a verso que conhece), o servidor pode enviar a sequncia de operaes necessrias
para actualizar a rplica do cliente. Caso contrrio, necessrio propagar uma cpia do coob-
//------------------ UTILIDADES ----------------------------------------------------------
// Gera semente para gerador de identificadores nicos
UIDSeed genUIDSeed();
//------------------ GESTO DE VOLUMES : ADMINISTRADORES ---------------------------------
// Cria novo volume
void createVolume( String volumeName);
// Inicia/cessa replicao do volume indicado
void replicateVolume( String volumeName, MbrshipElement fromServer);
void unreplicateVolume( String volumeName);
// Fora sincronizao do volume ou coobjecto indicado
void synchronizeVolume( String volumeName, MbrshipElement fromServer);
void synchronizeObject( GlobalOID goid, MbrshipElement fromServer)
// Lista volumes replicados no volume dado
String[] listVolumes();
//------------------ ACESSO AOS COOBJECTOS / SUB-OBJECTOS : UTILIZADORES -----------------
// Obtm cpia/actualizao do coobjecto/sub-objectos indicados para actualizar a verso indicada
ExtRepresentation getCoObject( Timevector state, Timevector view, GlobalOID[] goid, int falgs);
ExtRepresentation getCoObject(Timevector state,Timevector view, GlobalOID goid, CachePolicy policy, int flags);
ExtRepresentation getAddSubObject( Timevector state, Timevector view, GlobalOID goid, int flags);
// Submete sequncia de operaes executadas num coobjecto
OpId submitChanges( GlobalOID goid, Timevector viewID, OperationSeq ops);
// Grava novo coobjecto
void submitNewCoObject( GlobalOID goid, ObjectLLRepresentation objCore);
// Submete uma operao de interrogao/modificao para execuo sncrona
byte[] submitSyncQuery( RemoteSession session, OperationSingle op);
byte[] submitSyncOperation( RemoteSession session, OperationSeq op);
Figura 6.2: Interface do servidor.
jecto/subobjecto. Do ponto de vista do sistema, o estado de um coobjecto (transmitido como
resultado desta operao) inclui os atributos do sistema e uma sequncia opaca de bytes obtida
atravs dum mtodo do coobjecto. Os atributos do sistema permitem obter a fbrica do coob-
jecto
6
, a qual usada para armazenar e criar uma cpia do coobjecto a partir da sequncia de bytes
recebida do servidor. Os subobjectos so transmitidos para os clientes de forma semelhante aos
coobjectos, com excepo de a transmisso de um subobjecto (ou conjunto de subobjectos) ter de
ser efectuada no mbito do coobjecto em que o subobjecto est includo (i.e., quando se propaga
o estado de um subobjecto necessrio propagar o estado do coobjecto correspondente, a menos
que a verso actual do coobjecto seja conhecida no cliente).
getAddSubObject Permite, ao cliente, obter uma cpia de um subobjecto consistente com a cpia par-
cial do coobjecto que o cliente possui (e cuja verso indicada na operao). A execuo desta
operao semelhante anterior, com a seguinte diferena: o servidor deve enviar a verso do
subobjecto indicada (e no uma verso mais recente) ou devolver um erro. Esta operao permite
6
O cliente pode ter a necessidade de obter o cdigo da fbrica para completar a recepo da cpia de um coob-
jecto/subobjecto. Para tal, deve obter uma cpia do coobjecto que armazena o cdigo da fbrica.
6.2. SERVIDORES 93
ao cliente completar a sua cpia parcial, como se descreve na seco 6.3.1.
submitChanges Permite, ao cliente, enviar uma sequncia de operaes executadas num coobjecto.
Uma sequncia de operaes contm o identicador da verso qual as operaes foram executa-
das de forma a permitir traar as dependncias causais das operaes. Quando este identicador
de verso corresponder a uma vista diferente da vista actualmente instalada, o identicador actu-
alizado recorrendo a uma funo denida no coobjecto de liao. O servidor entrega a sequncia
de operaes recebida cpia local do coobjecto atravs duma operao denida na interface do
coobjecto.
submitNewCoObject Permite, ao cliente, enviar para o servidor o estado de um novo coobjecto criado
no cliente. Como anteriormente, este estado contm os atributos do sistema e uma sequncia
opaca de bytes obtida no cliente atravs da interface do coobjecto. Um mtodo denido na fbrica
do coobjecto responsvel por criar, usando a sequncia de bytes recebida do cliente, a cpia
inicial do coobjecto (incluindo todos os subobjectos denidos inicialmente) no servidor. Para criar
um coobjecto de um novo tipo, necessrio criar primeiro o coobjecto que armazena o cdigo
necessrio para o instanciar.
submitSyncQuery Permite, a um cliente, enviar uma operao de leitura para execuo imediata no ser-
vidor. O servidor executa imediatamente a operao na cpia local do coobjecto usando a interface
do coobjecto. O servidor devolve ao cliente, no apenas o resultado da operao executada, mas
tambm, a verso do coobjecto qual foi executada. Esta operao permite especicar condies
para a execuo da operao por exemplo, pode indicar-se que apenas se pretende executar
a operao numa dada verso do coobjecto (ver detalhes na seco 6.3.3). Se o servidor no se
encontra nas condies indicadas, a operao no executada, devolvendo um erro ao cliente.
submitSyncOperation Permite, a um cliente, submeter uma sequncia de operaes de modicao
para execuo imediata. Como anteriormente, o servidor entrega imediatamente a operao
cpia local do coobjecto para execuo. O servidor devolve ao cliente a verso da cpia local do
coobjecto aps as operaes terem sido entregues (a execuo imediata destas operaes na cpia
local do servidor no garantida, pois depende da estratgia de reconciliao usada no coobjecto).
De forma semelhante operao anterior, possvel especicar condies para a execuo da
operao.
Como se observa pelas descries anteriores, o ncleo do sistema delega nos coobjectos a maioria
das aces que devem ser executadas. Esta aproximao permite manter o ncleo do sistema simples, ao
mesmo tempo que permite a implementao de diferentes solues de gesto de dados partilhados.
6.2.5 Recursos associados aos coobjectos
Em cada servidor, o ncleo do sistema gere um conjunto de recursos associados a cada coobjecto. Estes
recursos consistem num conjunto de cheiros e bases de dados usados por cada coobjecto para armazenar
o seu estado actual. Cada subobjecto pertencente a um coobjecto tem igualmente associado um conjunto
de recursos geridos pelo sistema.
O ncleo do sistema responsvel por criar, remover e gerir todos os recursos usados pelos coob-
jectos/subobjectos de acordo com os seus pedidos. Para tal, o ncleo do sistema fornece uma interface
que permite manipular estes recursos (por exemplo, ler/gravar uma sequncia de bytes num cheiro,
questionar e modicar uma base de dados).
O estado de um coobjecto/subobjecto transmitido entre servidores ou para um cliente como uma
sequncia de bytes (opaca para o sistema). Esta sequncia criada por uma funo do coobjecto que
codica o seu estado actual, incluindo todos os recursos a ele associados.
6.2.6 Suporte para mltiplas bases de dados
Para permitir que os coobjectos/subobjectos armazenem o seu estado interno numa base de dados, cada
servidor e cada cliente tm associado um sistema de gesto de bases de dados. O ncleo do sistema
encarrega-se de criar/destruir/gerir as bases de dados no sistema de gesto de base de dados de acordo
com as necessidades dos coobjectos (os quais apenas tm acesso a uma referncia que lhes permite
aceder base de dados para leitura e escrita).
O prottipo do sistema DOORS permite a utilizao de trs sistema de gesto de bases de dados:
Hypersonic SQL [71] em qualquer plataforma (e usado por omisso); Microsoft Access [104] em plata-
formas Windows; e Oracle 8 [113] em qualquer plataforma.
Para permitir que em vrios servidores sejam usadas diferentes bases de dados de forma transparente,
criou-se, para cada base de dados, uma camada de uniformizao responsvel por fornecer uma viso
uniforme do servio. Esta camada responsvel por fornecer um mtodo uniforme de criar e remover ba-
ses de dados. Relativamente s instrues de acesso base de dados, esta camada devia limitar-se a ltrar
as operaes permitidas, restringido-as a um subconjunto de instrues universalmente suportadas (apro-
ximadamente as instrues do SQL92 [76]). Na prtica, vericou-se que necessrio efectuar pequenas
modicaes nas instrues submetidas base de dados, de forma a garantir a utilizao transparente de
diferentes bases de dados. Entre estas modicaes destacam-se:
Introduo/remoo de um carcter terminador nas instrues de leitura/escrita;
Converso dos nomes dos tipos de dados nas instrues de criao de novas tabelas;
Converso na forma como se denem restries na criao de novas tabelas;
6.2. SERVIDORES 95
Emulao do tipo de dados inteiro auto-incrementado na base de dados Oracle (combinando a
utilizao de sequncias e gatilhos (triggers)).
A ordem pela qual so devolvidos os resultados de uma instruo de leitura (select) no se encontra
denida. Assim, para que se tenha uma viso uniforme do servio de base de dados necessrio ordenar
o resultado de todas as instrues de leitura (por exemplo, transformando uma instruo select numa
instruo select. . .order by). No entanto, como a execuo de leituras ordenadas pode ser ineciente e a
ordem dos resultados no importante em muitas situaes, decidiu-se no integrar esta funcionalidade
na camada de uniformizao. Assim, os programadores so responsveis por efectuar leituras ordenadas
sempre que a ordem importante para o determinismo de uma operao.
6.2.7 Servio de awareness
Cada servidor do sistema DOORS tem associado um servio de awareness. Este servio responsvel
por entregar as mensagens produzidas pelos coobjectos aos servios que fazem a sua entrega nal aos
utilizadores. Para tal, este servio executa todos os passos necessrios ao contacto vel com os servios
nais, incluindo o tratamento de falhas temporrias.
O servio de awareness fornece uma interface normalizada para a propagao de mensagens atravs
de diferentes transportes. Adicionalmente, ao propagar as mensagens criadas durante a execuo de uma
operao de forma assncrona, permite que a execuo das operaes nos coobjectos seja rpida.
O modo como cada servio nal deve ser contactado denido em cada servidor. Para tal, dene-se
o cdigo (plug-in) usado para contactar o servio e os seus parmetros de congurao especca. Por
exemplo, no prottipo do sistema DOORS possvel usar os seguintes tipos de transporte (congurveis
em cada servidor):
Correio electrnico As mensagens so entregues ao servidor de SMTP especicado como parmetro
da congurao.
Mensagens SMS As mensagens so entregues atravs de um intermedirio (gateway) acessvel por
HTTP. O endereo do intermedirio congurvel.
Mensagens Deeds As mensagens so entregues ao servidor Deeds local.
Quando um coobjecto solicita a propagao de uma mensagem usando um mecanismo desconhecido
no servidor, o servio de awareness informa o coobjecto que no pode conrmar o processamento da
mensagem. O coobjecto pode, posteriormente, questionar o servio de awareness sobre a propagao da
mensagem.
//------------------ GESTO DE VOLUMES : ADMINISTRADORES ---------------------------------
// Cria novo volume
void createVolume( String inServer, String volumeName);
// Inicia/cassa replicao do volume indicado
void replicateVolume( String inServer, String volumeName, MbrshipElement fromServer);
void unreplicateVolume( String inServer, String volumeName);
// Fora sincronizao do volume/coobjecto indicado
void synchronizeVolume( String inServer, String volumeName, String fromServer);
void synchronizeObject( String inServer, CoobjId id, String fromServer)
// Lista volumes replicados num servidor
String[] listVolumes( String server);
// Lista identificadores de volumes com um dado nome
String[] listVolumeIds( String volumeName, int wait);
//------------------ ACESSO AOS COOBJECTOS : UTILIZADORES --------------------------------
// L um coobjecto existente
public CoObject getCoObject( CoobjId id, int flags);
public CoObject getCoObject( CoobjId id, CachePolicy policy, int flags);
// "Grava" as modificaes efectuadas no coobjecto
public void putCoObject( CoObject proxy);
// Armazena o coobjecto dado no sistema com o nome "id"
public void putCoObject( CoObject proxy, CoobjId id);
// Remove o coobjecto "id"
public void deleteCoObject( CoobjId id);
// L/grava atributos de um coobjecto existente
public CoObjectAttrib getCoObjectAttrib( CoobjId id, int flags);
void putCoObjectAttrib( CoObjectAttrib attrib); //sistema
Figura 6.3: API do sistema DOORS.
Assincronamente, o servio de awareness usa o servio de descoberta para procurar outros servidores
que saibam propagar a mensagem usando o mtodo solicitado pelo coobjecto. Se possvel, o servidor
importa o cdigo e as denies necessrias para processar localmente as mensagens. Caso tal no seja
possvel, o servidor propaga as mensagens para serem processadas noutro servidor.
6.3 Clientes
Os clientes do sistema DOORS fornecem s aplicaes uma interface que lhes permite aceder aos coob-
jectos e administrar os servidores ver gura 6.3. Para fornecerem estes servios, os clientes acedem
s operaes disponibilizadas pelos servidores descritas na seco 6.2.4. Adicionalmente, para permitir
o acesso aos dados em situaes de desconexo, os clientes mantm cpias parciais dos coobjectos. O
modo de funcionamento do cliente detalhado nesta seco.
Os clientes mantm cpias parciais dos coobjectos. Uma cpia parcial de um coobjecto consiste na
parte comum do coobjecto e num subconjunto dos subobjectos contidos no coobjecto. A parte comum
6.3. CLIENTES 97
do coobjecto consiste nos componentes necessrios (cpsula, atributos do sistema, etc.) criao de
uma cpia do coobjecto. De forma semelhante ao servidor, para cada coobjecto/subobjecto replicado
localmente, o cliente mantm um conjunto de recursos no qual est armazenado o seu estado actual.
Os clientes obtm as cpias parciais a partir de um qualquer servidor. Com cada cpia de um coob-
jecto (e respectivos subobjectos), o cliente mantm o identicador da vista no servidor quando a cpia
foi obtida. Este identicador da vista usado em todas as interaces com os servidores para que estes
possam interpretar correctamente os identicadores das operaes (e vectores verso).
Actualizao da cpia parcial de um coobjecto Uma cpia parcial de um coobjecto pode ser actuali-
zada a partir de qualquer servidor. Se o servidor tem instalada uma vista diferente da vista usada na cpia
do cliente, o cliente deve contactar um novo servidor ou obter uma cpia nova a partir deste servidor.
Para determinar se a cpia de um cliente necessita de ser actualizada, o servidor compara a verso
do coobjecto da sua cpia local, o.v, e a verso do coobjecto que o cliente possui, rv. Se os dois vectores
forem iguais (o.v[i] = rv[i], i), a cpia do cliente est actualizada. Se o vector do servidor for superior
ao do cliente, i.e., o.v[i] rv[i], i, o servidor tem uma verso mais recente e a verso do cliente pode ser
actualizada. Se o vector do servidor for inferior ao do cliente, i.e., o.v[i] rv[i], i, o servidor tem uma
verso mais antiga do que a verso do cliente (obtida a partir de outro servidor) neste caso, o cliente
tem a opo de obter a cpia mais antiga (o comportamento desejado especicado como parmetro da
operao getCoObject). Se nenhuma das situaes anteriores se vericar, o cliente e o servidor possuem
verses concorrentes do coobjecto (cada uma reecte operaes que a outra no reecte) neste caso,
a verso do cliente no pode ser actualizada, mas o cliente pode obter uma nova cpia.
Quando a cpia parcial de um cliente actualizada, o servidor pode enviar para o cliente uma nova
cpia do estado do coobjecto (incluindo todos os subobjectos modicados nos quais o cliente est inte-
ressado) ou uma sequncia de operaes a executar no cliente para actualizar a cpia local. Quando se
usa esta segunda opo, o cliente executa a sequncia de operaes recebidas pela ordem indicada. Se
ocorrer algum erro durante a execuo das operaes no cliente (por exemplo, devido ao facto de no
existir uma cpia local de um subobjecto usado), o cliente obtm uma nova cpia do estado do coobjecto.
A actualizao dum coobjecto deve incluir a actualizao de todos os subobjectos contidos na cpia
parcial do cliente caso contrrio, a cpia local caria inconsistente. Quando a actualizao da cpia de
um coobjecto no cliente efectuada atravs da propagao do estado do coobjecto, o servidor verica a
necessidade de enviar uma nova cpia de um subobjecto. Esta vericao efectuada determinando se
alguma operao que ainda no est reectida na cpia do cliente modicou o subobjecto considerado,
i.e, se i : so.v[i] > rv[i], com so.v o sumrio das operaes que modicaram o subobjecto e rv a verso
do coobjecto no cliente (note-se que podem ter sido executadas novas operaes no servidor que no
tenham modicado o subobjecto). Neste caso, o servidor envia uma nova cpia do subobjecto.
Aumento da cpia parcial de um coobjecto Por vezes, a cpia parcial presente no cliente no
suciente para satisfazer as necessidades de uma aplicao que est a manipular um coobjecto, i.e., o
utilizador pretende aceder a um subobjecto do qual o cliente no possui uma cpia local. Neste caso, o
cliente necessita de aumentar a sua cpia local, obtendo uma cpia do subobjecto que seja consistente
com a cpia do coobjecto que possui.
Uma cpia de um subobjecto consistente com a cpia de um coobjecto, se o estado do subobjecto
reectir a execuo de todas as operaes reectidas no estado do coobjecto e apenas essas. Um servidor
verica se a cpia local de um subobjecto consistente com a cpia de um coobjecto de um cliente,
sendo rv a verso do coobjecto, vericando se: (1) a cpia local do coobjecto reecte todas as operaes
reectidas no cliente, i.e, o.v[i] rv[i], i, com o.v a verso do coobjecto no servidor; (2) o subobjecto
no foi alterado por operaes no reectidas na cpia do cliente, i.e., so.v[i] rv[i], i em que so.v o
sumrio das operaes que modicaram o subobjecto no servidor. Se a cpia no servidor for consistente
com a do cliente, o servidor pode enviar o subobjecto para o cliente. Caso contrrio, o cliente no pode
aumentar a sua cpia parcial a partir desse servidor.
6.3.2 Detalhes do funcionamento dos coobjectos
O funcionamento geral dos coobjectos nos clientes foi descrito na seco 3.2.2.2. Nesta seco descre-
vem-se pormenores da implementao do modelo descrito no prottipo do sistema DOORS.
Como se descreveu na seco 6.1, as aplicaes manipulam cpias privadas dos coobjectos criadas
pelo ncleo do sistema. Cada cpia inclui uma referncia no sistema (handle) que permite, quando
necessrio, criar cpias de outros subobjectos consistentes com a verso actual. Esta referncia permite
ainda: aceder aos recursos associados ao coobjecto e aos subobjectos nele contidos; e submeter operaes
para execuo imediata nos servidores.
Quando uma aplicao obtm uma cpia de um coobjecto pode indicar um conjunto de propriedade
a satisfazer pela cpia obtida. Primeiro, pode obter-se uma cpia local, sem que o cliente contacte o
servidor. Neste caso, a aplicao pode optar pela cpia obtida do servidor ou por uma cpia provisria,
resultado da ltima gravao efectuada localmente por uma aplicao. Segundo, a aplicao pode soli-
citar que o cliente obtenha uma verso a partir de um servidor. Terceiro, a aplicao pode solicitar que o
cliente devolva uma verso que respeite uma das seguintes propriedades:
Verso sucessiva A verso do coobjecto obtida posterior s verses obtidas anteriormente.
L modicaes A verso do coobjecto obtida reecte as modicaes executadas anteriormente pelo
utilizador.
Para garantir estas propriedades, o cliente mantm, para cada utilizador e para cada coobjecto, a
6.3. CLIENTES 99
seguinte informao (independentemente de, no momento, manter uma cpia desse coobjecto).
Primeiro, um vector verso, r, que reecte as operaes observadas nas verses lidas anteriormente.
Este vector actualizado sempre que uma nova verso do coobjecto lida pelo utilizador, fazendo r[i] =
max(r[i], o.v[i]), com o.v a verso do coobjecto lida. A primeira propriedade garantida se a verso do
coobjecto a devolver, o.v, for superior ao vector r, i.e., o.v[i] r[i], i.
Segundo, o cliente mantm um vector temporal, w, que reecte as operaes escritas pelo utilizador.
Este vector actualizado sempre que uma operao submetida pelo utilizador propagada para o servi-
dor, fazendo w[id.srv
view
] = id.n_seq, com id o identicador da operao submetida (este identicador
devolvido pelo servidor). A segunda propriedade garantida se a verso do objecto a devolver, o.v, for
superior ao vector w, i.e., o.v[i] w[i], i.
Finalmente, o cliente mantm o identicador da vista em que os vectores temporais anteriores so
vlidos. Quando o cliente detecta uma mudana de vista, os vectores temporais anteriores so convertidos
na nova vista usando a operao disponibilizada no coobjecto de liao.
As propriedades referidas anteriormente apenas so garantidas para acessos executados a partir de
um mesmo cliente e pelo perodo de tempo indicado na congurao do cliente. Se um utilizador no
aceder a um coobjecto durante o perodo de tempo indicado, a informao do utilizador relativa a esse
coobjecto removida.
Quando uma aplicao grava as modicaes efectuadas a umcoobjecto, o cliente extrai as operaes
executadas e guarda-as emmemria estvel para posterior propagao para o servidor. Aps as operaes
estarem guardadas em memria estvel, o coobjecto informado do facto e a aplicao pode continuar a
manipular essa cpia do coobjecto (e executar novas gravaes mais tarde).
Sempre que possvel (i.e., desde que as primeiras sequncias ainda no tenham sido propagadas),
o cliente combina as sequncias de operaes que resultam de modicaes mesma cpia privada
de um coobjecto numa nica sequncia, de forma a reectir a causalidade existente na sua execuo.
Quando isso no possvel, o cliente garante que envia as operaes para o mesmo servidor por ordem
de gravao.
Alm de extrair a sequncia de operaes executadas para propagao para um servidor, o cliente
grava o estado actual do coobjecto como uma verso provisria. Desta forma, em sucessivos acessos
a um coobjecto durante um perodo de desconexo, os utilizadores podem observar as modicaes
efectuadas anteriormente. Se as limitaes de espao disponvel para as cpias locais o permitirem, o
cliente mantm tambm a verso obtida directamente do servidor.
Quando uma aplicao grava um novo coobjecto, o cliente obtm uma cpia do estado actual do
coobjecto, que propagada para o servidor para servir como estado inicial do coobjecto.
6.3.3 Execuo sncrona e garantias de sesso
Os clientes do sistema DOORS fornecem um servio que permite aos coobjectos executar operaes
de leitura e escrita imediatamente num servidor. Este servio est disponvel a partir da referncia de
sistema (handle) associado a cada cpia de um coobjecto. O cliente responsvel pela propagao das
operaes para um servidor e obteno dos respectivos resultados.
Como as rplicas de um coobjecto nos vrios servidores so fracamente consistentes, seria possvel
que sucessivas operaes sncronas observassem estados inconsistentes do coobjecto por exemplo,
uma leitura executada num servidor podia reectir uma operao que no fosse reectida numa leitura
posterior executada noutro servidor. Para que esta situao no ocorra, possvel especicar as garan-
tias de sesso [162] que se pretende que as sucessivas invocaes sncronas respeitem. As seguintes
propriedades podem ser especicadas:
Verso sucessiva A verso do coobjecto lida posterior s verses lidas anteriormente.
L modicaes A verso do coobjecto lida reecte as modicaes executadas anteriormente.
Servidor nico Todas as operaes so executadas no mesmo servidor.
Estas propriedades so garantidas de forma semelhante s propriedades fornecidas na obteno de
uma cpia de um coobjecto no cliente, mas mantendo os vectores temporais no mbito da sesso remota.
Os coobjectos devem utilizar este servio respeitando as intenes dos utilizadores. Em especial,
necessrio ter em ateno que a propagao sncrona de uma operao de modicao equivale sua
gravao o utilizador no pode, posteriormente, desfazer a sua execuo (embora possa executar uma
operao que anule os seus efeitos). Desta forma, os utilizadores devem estar conscientes das situaes
em que uma operao executada vai ser propagada para um servidor.
6.3.4 Servios bsicos
Um cliente do sistema DOORS possui dois subsistemas bsicos: o subsistema de comunicaes e o
subsistema de replicao antecipada.
O subsistema de comunicaes usado para contactar os servidores e os outros clientes. Este ser-
vio disponibiliza uma interface comum para a propagao de mensagens usando diferentes transportes
(no prottipo do sistema DOORS usa-se RMI). Dois tipos de propagao esto disponveis: sncrona
e assncrona. A propagao sncrona usada pelo cliente quando precisa de uma resposta imediata s
mensagens que est a enviar por exemplo, durante a invocao sncrona de operaes e quando
necessrio obter uma cpia de um coobjecto/subobjecto para entregar imediatamente a uma aplicao.
A semntica da propagao sncrona no mximo uma vez (at-most once).
6.3. CLIENTES 101
A propagao assncrona usada quando o cliente no necessita obter uma resposta imediata s
mensagens enviadas por exemplo, quando propaga as modicaes executadas por um utilizador a
um coobjecto. A semntica da propagao assncrona exactamente uma vez (exactly-once) (desde
que o cliente no que denitivamente desconectado do servidor). Para tal, o subsistema de comu-
nicaes mantm em memria estvel a informao (contedo das mensagens, nmeros de sequncia
enviados/recebidos/garantidos) sobre as mensagens a enviar para os os diferentes parceiros (servidores e
outros clientes).
O subsistema de replicao antecipada (pre-fetching) responsvel por manter na cache do cliente
as cpias dos coobjectos necessrias para que os utilizadores continuem o seu trabalho em situaes de
desconexo. Este subsistema tem acesso informao de quais os coobjectos/subobjectos acedidos por
cada utilizador. Como se referiu anteriormente, o problema de determinar, de forma eciente, quais so
os dados que devem ser obtidos para suportar a operao desconectada est fora do mbito do trabalho
apresentado nesta dissertao. A soluo implementada no prottipo DOORS bastante simples e basei-
a-se numa poltica de replicao menos recentemente utilizado (least recently used) e na actualizao
peridica dos coobjectos/subobjectos replicados no cliente.
6.3.5 Comunicao entre clientes
Por vezes, dois clientes que se encontram desconectados dos servidores conseguem comunicar directa-
mente entre si (por exemplo, usando redes de comunicao ad hoc estabelecidas usando dispositivos de
rede Bluetooth [19] ou wireless ethernet [73]). No sistema DOORS permite-se que os clientes explorem
estas comunicaes para actualizao do estado das suas rplicas secundrias.
Cada cliente implementa uma interface que permite aos outros clientes obter cpias de coobjec-
tos/subobjectos. Esta interface consiste nas operaes getCoObject e getAddSubObject, denidas de
forma idntica da interface do servidor (e descritas na seco 6.2.4). Quando um cliente, i, recebe uma
operao getCoobject (ou getAddSubObject) de outro cliente, j, podem ocorrer as seguintes situaes.
O cliente i no tem nenhuma cpia do coobjecto/subobjecto pedido. Neste caso a operao aborta
e o cliente j informado do erro.
O cliente i possui uma cpia inalterada do coobjecto/subobjecto pedido. Neste caso, o cliente i
actua de forma semelhante a um servidor, enviando para j o estado actual do coobjecto/subobjecto.
O cliente i possui uma cpia provisria do coobjecto/subobjecto pedido, reectindo as modica-
es efectuadas em i aps o coobjecto/subobjecto ter sido obtido a partir de um servidor. Neste
caso, o cliente i responde com base na cpia obtida do servidor ou na verso provisria em funo
das opes especicadas pelo cliente j.
Ao permitir que os clientes propaguem entre si verses modicadas dos coobjectos/subobjectos, per-
mite-se que os utilizadores observem imediatamente as operaes executadas provisoriamente por ou-
tros utilizadores. Apesar de a execuo dessas operaes ser provisria, os utilizadores podem (devem)
evitar operaes que entrem em conito com as operaes executadas pelos outros utilizadores. Adicio-
nalmente, necessrio ter em ateno que, em geral, para as operaes executadas posteriormente num
cliente no registada a dependncia relativa s operaes provisrias executadas nos outros clientes
(embora seja possvel manter essa informao). Este problema foi discutido na seco 4.1.
6.3.6 Servio de awareness
De forma semelhante ao que acontece no servidor, cada cliente do sistema DOORS tem associado um
servio de awareness. O objectivo deste servio permitir aos utilizadores terem conhecimento das
actividades que os outros utilizadores esto a executar concorrentemente. No cliente, este servio apenas
permite a propagao de informao utilizando o sistema de disseminao de eventos Deeds [45].
6.4 Sumrio
Neste captulo descreveu-se o ncleo do sistema DOORS e a sua implementao no prottipo criado. O
ncleo do sistema fornece os servios bsicos necessrios para suportar o modelo do sistema DOORS.
O prottipo do sistema comprova a exequibilidade do modelo proposto.
O modelo de funcionamento do sistema DOORS, incluindo as suas principais caractersticas e tcni-
cas usadas para a gesto de dados partilhados num ambiente de computao mvel foram apresentadas
nos captulos 3 e 4. A utilizao do modelo proposto para suportar aplicaes cooperativas tipicamente
assncronas foi descrito no captulo 5.
Nos prximos captulos apresenta-se um sistema de gesto de bases de dados relacionais para am-
bientes de computao mvel. Apesar desse sistema partilhar com o sistema DOORS um conjunto de
princpios bsicos, as tcnicas usadas para colocar esses princpios em prtica so distintas.
Captulo 7
Apresentao do sistema Mobisnap
Nos prximos captulos descreve-se um sistema de gesto de bases de dados para ambientes de com-
putao mvel: o sistema Mobisnap [126, 33, 128]. Este sistema tem por objectivo permitir que mlti-
plos utilizadores acedam e modiquem uma base de dados relacional, a partir de computadores mveis,
mesmo durante os perodos de desconexo. Na seco 2.2 foram apresentadas algumas das aplicaes
tpicas que se pretendem suportar com este sistema: um sistema de suporte a uma fora de vendas mvel,
um sistema de reserva de lugares e uma agenda partilhada.
O sistema Mobisnap construdo como uma camada intermdia de sistema (middleware) e baseia-se
numa arquitectura cliente estendido/servidor [78]. O servidor mantm a cpia principal dos dados. Os
clientes mantm cpias parciais para fornecer uma elevada disponibilidade de acesso. As aplicaes
modicam o estado da base de dados atravs da submisso de pequenos programas escritos na linguagem
PL/SQL [112]. Este programas, designados transaces mveis, so executados de forma provisria no
cliente e, mais tarde, de forma denitiva, no servidor.
Para permitir garantir os resultados das transaces mveis nos clientes, os utilizadores podem obter
reservas sobre os dados. Este mecanismo de reservas, detalhado no captulo 8, permite garantir que no
surgir nenhum conito quando uma transaco executada no servidor. No captulo 9 apresenta-se uma
avaliao do modelo do sistema Mobisnap, incluindo o sistema de reservas. No captulo 10 descreve-se
um mecanismo de reconciliao que permite optimizar o conjunto de transaces mveis que podem
ser executadas. At ao nal deste captulo descreve-se o modelo geral, a arquitectura do sistema e
detalham-se as transaces mveis.
7.1 Modelo geral
O sistema Mobisnap um sistema de gesto de bases de dados para ambientes de computao mvel
baseado numa arquitectura cliente estendido/servidor. O servidor mantm a cpia principal da base
103
104 CAPTULO 7. APRESENTAO DO SISTEMA MOBISNAP
1 -- ENCOMENDA DE PRODUTO: nome = "BLUE THING"; quantidade = 10; preo mximo = 50.00
2 -- alternativa: nome = "RED THING"; quantidade = 5; preo mximo = 40.00
3 DECLARE
4 prd_price FLOAT;
5 prd_stock INTEGER;
6 BEGIN --- Primeira alternativa ---
7 SELECT price,stock INTO prd_price,prd_stock FROM products WHERE name=BLUE THING;
8 IF prd_price <= 50.00 AND prd_stock >= 10 THEN
9 UPDATE products SET stock = prd_stock - 10 WHERE name = BLUE THING;
10 INSERT INTO orders VALUES(newid,Clt foo,BLUE THING,10,prd_price,to ptocess);
11 NOTIFY( SMTP, sal-07@thingco.pt, Encomenda aceite...);
12 COMMIT (BLUE THING,prd_price); -- Conclui a transaco e devolve
13 END IF; -- informao sobre a encomenda efecutada
14 --- Segunda alternativa ---
15 SELECT price,stock INTO prd_price,prd_stock FROM products WHERE name=RED THING;
16 IF prd_price <= 40.00 AND prd_stock >= 5 THEN
17 UPDATE products SET stock = prd_stock - 5 WHERE name = RED THING;
18 INSERT INTO orders VALUES(newid,Clt foo,RED THING,5,prd_price,to ptocess);
20 COMMIT (RED THING,prd_price); -- Conclui a transaco e devolve informao sobre a
21 END IF; -- encomenda efecutada
22 ROLLBACK; -- Caso nenhuma alterantiva seja aceitvel aborta a transaco
23 ON ROLLBACK NOTIFY( SMS, 351927435456, Encomenda impossvel...);
24 END;
Figura 7.1: Transaco mvel que introduz uma nova encomenda, com dois produtos alternativos, sub-
metida por um vendedor.
de dados que representa o estado ocial dos dados. Os clientes mantm cpias parciais, fracamente
consistentes, dos dados. Uma cpia parcial contm um subconjunto de tabelas. Para cada tabela, apenas
mantido um subconjunto de colunas. Finalmente, apenas um subconjunto dos registos de cada tabela
est contido na cpia parcial. A possibilidade de cada cliente manter apenas os dados que necessita (e
pode armazenar) importante para permitir a utilizao do sistema em dispositivos mveis com recursos
limitados (por exemplo, PDAs), como se referiu na seco 2.3.5.
As aplicaes so executadas nos clientes. O sistema adopta uma poltica optimista de acesso aos
dados, na qual as aplicaes podem aceder e modicar a cpia mantida no cliente. A esta cpia, na qual
se executam todas as transaces submetidas no cliente, chama-se verso provisria dos dados. Quando
os recursos disponveis no cliente o permitem, o cliente mantm adicionalmente uma verso estvel dos
dados, a qual mantm a cpia obtida a partir do servidor, modicada com as transaces executadas
localmente cujo resultado pode ser garantido pelo sistema de reservas (detalhado no prximo captulo).
As aplicaes podem aceder a ambas as verses. Durante os perodos de boa conectividade, as aplicaes
podem aceder directamente ao servidor.
Transaces mveis As aplicaes modicam o estado da base de dados submetendo pequenos pro-
gramas escritos num subconjunto estendido da linguagem PL/SQL [112], que se denominam transaces
mveis (ou simplesmente transaces, nas situaes em que a sua utilizao no possa levar a interpreta-
es incorrectas). Na gura 7.1 apresenta-se um exemplo de uma transaces mvel para submeter uma
encomenda de um produto, propondo duas possveis alternativas.
A execuo de uma transaco mvel corresponde sempre execuo do seu programa numa cpia
da base de dados. As transaces mveis so executadas imediatamente no cliente produzindo um re-
sultado provisrio (e modicando o estado da verso provisria dos dados). As transaces mveis so
posteriormente propagadas para o servidor onde so reexecutadas. O resultado denitivo de uma tran-
saco mvel (e o modo como afecta a cpia principal dos dados) resulta da sua execuo no servidor.
O modelo de execuo das transaces mveis, com o resultado denitivo a ser determinado pela
execuo do cdigo da transaco no servidor, permite a denio de regras de deteco e resoluo
de conitos especcas para cada operao. Estas regras devem garantir o respeito pelas intenes dos
utilizadores explorando a informao semntica associada aos tipos de dados e operaes denidas. A
transaco da gura 7.1 exemplica algumas das estratgias que podem ser utilizadas.
Primeiro, as pr-condies para a execuo da operao so especicadas de forma exacta (condi-
es das linhas 8 e 16). Assim, a transaco no abortada se os valores observados no cliente e no
servidor forem diferentes, mas apenas se as condies expressas forem violadas. Esta aproximao per-
mite reduzir o nmero de falsos conitos detectados, quando comparada com as tcnicas que foram a
igualdade dos valores lidos no cliente e no servidor (usuais em sistemas de bases de dados). Segundo,
a transaco especica vrias alternativas. Esta aproximao representa uma forma simples de resolver
eventuais conitos desde que uma das alternativas seja possvel.
Uma aplicao pode submeter transaces mveis que modiquem dados no replicados no cliente.
Neste caso, apesar de no ser possvel obter um resultado provisrio, a transaco pode ser propagada
para o servidor onde o resultado nal obtido executando o programa da transaco na base de dados
do servidor. Esta aproximao permite aos utilizadores continuarem o seu trabalho mesmo quando no
possvel obter uma cpia dos dados (como se referiu na seco 2.3.6).
Quando o resultado denitivo de uma transaco mvel obtido no servidor, os utilizadores podem
j no estar a utilizar o sistema. Assim, como se referiu na seco 2.3.4, importante integrar um
mecanismo que possibilite informar os utilizadores sobre os resultados denitivos das suas operaes.
No sistema Mobisnap, deniu-se uma funo que pode ser usada nas transaces mveis para enviar
mensagens aos utilizadores atravs de diferentes transportes. Esta funo processada de forma especial
pelo sistema, apenas produzindo efeito na execuo denitiva da transaco mvel. Adicionalmente, o
sistema encarrega-se de garantir a propagao destas mensagens atravs do transporte indicado.
Reservas A possibilidade de garantir o resultado de uma transaco mvel de forma independente tem
vrias vantagens, como se discutiu na seco 2.3.7. Primeiro, permite suportar de forma mais adequada a
operao em situaes de desconexo. Segundo, mesmo quando possvel contactar o servidor, permite
reduzir o tempo de execuo das operaes e gerir de forma mais eciente as comunicaes entre os
clientes e o servidor, alm de permitir gerir a execuo dessas operaes no servidor de acordo com a
carga do sistema. O Mobisnap integra um sistema de reservas, detalhado no captulo 8, que permite aos
clientes obter garantias sobre os valores da base de dados. Caso o cliente disponha de reservas suciente,
o cliente pode garantir que no surgir nenhum conito quando a transaco mvel executada no
servidor, permitindo garantir o resultado da transaco de forma independente.
Alguns dos tipos de reservas denidos no sistema Mobisnap j foram utilizados noutros siste-
mas [111]. No entanto, a sua integrao num sistema unicado como o apresentado fundamental
para a sua utilidade. Considere-se o exemplo da gura 7.1. Usando tcnicas de diviso (escrow)
1
pos-
svel garantir a existncia de unidades sucientes de um produto para satisfazer o pedido. No entanto,
para que o sistema possa garantir o resultado da transaco igualmente necessrio que possa garantir
o valor do preo. Assim, seria necessrio usar outro tipo de garantia. Neste caso, poder-se-ia usar um
trinco (lock) apesar de essa tcnica ser desnecessariamente restritiva.
Uma propriedade importante do sistema de reservas a vericao transparente das reservas que
podem ser utilizadas para garantir uma transaco mvel. Esta vericao efectuada a partir do cdigo
da transaco, sem que seja necessrio especicar quaisquer instrues especiais. Assim, qualquer tran-
saco pode usar todas as reservas existentes e no apenas aquelas que a transaco est preparada para
utilizar.
O sistema faz respeitar as garantias relativas s reservas concedidas, no cando as propriedades as-
sociadas dependentes de convenes a cumprir pelas transaces. Assim, impede-se qualquer transaco
executada no sistema Mobisnap ou directamente na base de dados central de modicar a base de dados de
forma a violar as garantias relativas a qualquer reserva. Como as reservas so temporrias (leased) [58],
garante-se que as restries impostas s outras transaces no duram indenidamente, mesmo que o
cliente mvel, a quem a reserva foi concedida, seja destrudo ou que permanentemente desconectado.
No entanto, para que a garantia dada quanto ao resultado de uma transaco seja vlida necessrio que
a transaco seja propagada para o servidor antes das reservas usadas expirarem.
Reconciliao de mltiplas transaces O sistema Mobisnap inclui ainda um mecanismo de recon-
ciliao que permite criar um plano de execuo quase ptimo como resultado da reconciliao de um
conjunto de transaces mveis. A soluo proposta uma extenso do modelo do sistema IceCube [85],
e utiliza informao semntica extrada automaticamente das transaces mveis. Este mecanismo de
reconciliao genrico e pode ser usado independentemente em qualquer sistema de bases de dados
para reconciliar conjuntos de transaces executadas concorrentemente. Assim, este mecanismo apre-
1
As tcnicas de diviso (escrow) permitem dividir um recurso fungvel por vrias rplicas por exemplo, a existncia
(stock) de um produto pode ser dividido por vrios vendedores. Cada rplica pode decidir sobre a sua parte de forma indepen-
dente.
7.2. ARQUITECTURA 107

BD
rplica
principal
Servidor Mobisnap
cliente
legado
controle de execuo e
interpretador trx. mveis
sistema de replicao e
reservas
sistema de notificao
sistema de comunicaes
BD
rplica
Cliente Mobisnap
reservas
BD
rplica
Cliente Mobisnap
reservas

Figura 7.2: Arquitectura do sistema Mobisnap.
sentado de forma independente no captulo 10.
Aproximao evolutiva O modelo do sistema Mobisnap evolutivo, pois permite que aplicaes que
no 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 (transaces mveis,
reservas e reconciliao de mltiplas transaces) independentemente de qualquer modicao concor-
rente executada na base de dados central.
Adicionalmente, o sistema baseia-se na utilizao de linguagens normalizadas (SQL e PL/SQL).
Esta caracterstica, ao permitir que os programadores utilizem as funcionalidades do sistema atravs de
ferramentas que lhe so familiares permite facilitar o desenvolvimento de novas aplicaes que utilizem
as novas funcionalidades (como se discutiu na seco 2.3.8).
7.2 Arquitectura
A arquitectura do sistema Mobisnap baseada no modelo cliente estendido/servidor [78], como se re-
presenta na gura 7.2. O servidor deve executar numa mquina com boa conectividade (em geral, um
computador xo). O servidor mantm o estado ocial dos dados, ou seja, a rplica principal (e com-
pleta) da base de dados. Os clientes podem ser computadores xos ou mveis capazes de comunicar com
o servidor. Os clientes mantm cpias parciais dos dados.
O Mobisnap desenhado (e implementado) como uma camada de sistema intermdia (middleware).
Assim, o Mobisnap utiliza um sistema de gesto de bases de dados para gerir os dados no cliente e no
servidor. As funcionalidades do sistema Mobisnap so implementadas pelos componentes do sistema
recorrendo aos servios bsicos fornecidos pelo sistema de gesto de bases de dados.
O sistema Mobisnap apresenta uma aproximao evolutiva, permitindo aos clientes legados (legacy)
continuarem a aceder directamente base de dados central. Como bvio, os clientes que acedam
directamente base de dados central no podem utilizar as funcionalidades do sistema Mobisnap.
7.2.1 Servidor
O servidor Mobisnap composto por um conjunto de subsistemas que interagem para executar as funci-
onalidades do sistema Mobisnap.
O sistema de gesto de bases de dados mantm o valor da base de dados manipulada pelas aplicaes.
Adicionalmente, armazena, de forma estvel, toda a informao interna dos vrios componentes do
servidor.
Qualquer sistema de gesto de bases de dados que implemente as seguintes funcionalidades pode
ser usado num servidor Mobisnap. Primeiro, deve fornecer uma interface que utilize a linguagem
SQL92 [76]. Segundo, deve implementar um mecanismo de gatilhos (triggers), usado pelo subsistema
de reservas. Terceiro, deve implementar um mecanismo de transaces encaixadas (nested transacti-
ons) ou gravao e reposio total do estado (checkpoint), usado pelo mecanismo de reconciliao. No
prottipo do sistema Mobisnap usou-se o sistema de gesto de bases de dados Oracle 8 [113].
O subsistema de reservas efectua a gesto completa das reservas, como se detalha no prximo ca-
ptulo. No funcionamento deste subsistema podem ser identicadas trs actividades complementares.
Primeiro, o processamento dos pedidos de obteno de reservas. Segundo, o processamento das utiliza-
es das reservas. Terceiro, a gesto da validade das reservas no tempo e dos recursos a elas associados.
O subsistema de replicao responsvel por gerir a interaco com os clientes no mbito da gesto
das rplicas dos clientes. No prottipo do sistema, o servidor limita-se a processar os pedidos de obteno
e actualizao das cpias parciais secundrias submetidos pelos clientes. Estes pedidos so especicados
atravs de uma instruo de interrogao baseada na instruo SQL select.
Numa verso mais completa da gesto da replicao secundria, este subsistema pode ser responsvel
pelas seguintes actividades complementares. Primeiro, a inferncia de regras de acesso aos dados a serem
utilizadas pelo mecanismo de replicao antecipada (vrias solues foram propostas na literatura [87,
91]). Segundo, o controlo da divergncia entre a cpia principal e as cpias secundrias armazenadas
nos clientes (vrias solues foram propostas na literatura [6, 146, 173]). Como se referiu anteriormente,
estes problemas, relativos gesto da replicao secundria, esto fora do mbito desta dissertao.
O subsistema de controlo de execuo responsvel por controlar a execuo das transaces mveis
recebidas do cliente. Este processo, descrito na seco 7.3, efectuado utilizando um interpretador de
PL/SQL em que os comandos SQL so executados directamente sobre a base de dados
2
.
2
Esta aproximao permite que a base de dados utilizada no necessite de executar programas PL/SQL.
7.2. ARQUITECTURA 109
O subsistema de noticaes encarrega-se de entregar as mensagens produzidas durante a execuo
denitiva das transaces mveis aos servios que efectuam a sua entrega nal aos utilizadores. Este
subsistema executa as mesmas funes que o servio de noticaes do sistema DOORS, descrito na
seco 6.2.7.
O subsistema de comunicaes controla a troca de mensagens entre os clientes e os servidores usando
um modelo de propagao de mensagens sncrono ou assncrono. Quando se usa um modelo sncrono,
o subsistema executa uma semntica no mximo uma vez (at most once). Quando se usa um modelo
assncrono, o subsistema executa uma semntica exactamente uma vez (exactly-once).
No prottipo do sistema Mobisnap, so usados dois transportes na propagao de mensagens: TCP
e SMTP. O sistema de propagao implementa um modelo de segurana utilizando tcnicas de cripto-
graa. Este modelo baseado na denio de uma sesso segura de durao limitada que tem associada
uma chave de criptograa simtrica. A sesso estabelecida recorrendo a um modelo de criptograa
assimtrica. O subsistema de comunicao usado no sistema Mobisnap detalhado em [32, 33].
7.2.2 Cliente
O cliente Mobisnap composto por um conjunto de subsistemas que interagem para executar as funcio-
nalidades do sistema Mobisnap.
O sistema de gesto de bases de dados mantm as cpias parciais da base de dados manipulada pelas
aplicaes. Adicionalmente, armazena, de forma estvel, a informao interna dos vrios componentes
do cliente. O cliente Mobisnap pode utilizar diferentes bases de dados no prottipo do sistema Mo-
bisnap usa-se o Hypersonic SQL [71], uma sistema de gesto de bases de dados de pequena dimenso
(menor que 200 Kb) totalmente implementado em Java.
O subsistema de replicao controla a gesto das rplicas parciais mantidas pelo cliente. Como se
referiu anteriormente, o cliente mantm duas cpias da base de dados, uma verso estvel e uma verso
provisria. Estas cpias so actualizadas a partir dos servidores e durante a execuo local das transac-
es mveis. As aplicaes podem executar operaes de interrogao sobre cada uma das verses. No
prottipo actual, impossvel saber se os resultados obtidos so incompletos devido replicao parcial.
No entanto, atravs da introduo de um mecanismo de replicao secundria semntica [35, 142] seria
possvel indicar a completude do resultado.
O subsistema de reservas efectua a gesto das reservas no cliente. Duas actividades so executa-
das. Primeiro, para cada utilizador, mantm as reservas que podem ser utilizadas localmente. Segundo,
controla a utilizao das reservas nas transaces mveis executadas localmente.
Os subsistemas anteriores so, igualmente, responsveis por controlar a obteno e actualizao das
rplicas locais e das reservas obtidas. No prottipo actual, as aplicaes devem especicar quais os dados
e reservas a obter.
O subsistema de controlo de execuo responsvel por controlar a execuo das operaes efectua-
das pelas aplicaes. As operaes relativas gesto da replicao e das reservas so propagadas para os
subsistema relevantes. As operaes de interrogao so executadas directamente sobre as cpias locais
da base de dados. As transaces mveis so processadas como se descreve na seco 8.3, utilizando um
interpretador de PL/SQL e a informao sobre as reservas existentes. Aps serem executadas localmente,
as transaces mveis so armazenadas de forma estvel at serem propagadas para o servidor. O cliente
usa o mecanismo de compresso apresentado na seco 10.4.2 para comprimir a sequncia de operaes
a propagar.
O subsistema de comunicaes foi explicado anteriormente. No entanto, nos clientes, o subsistema
de comunicaes igualmente utilizado para as comunicaes entre os clientes (efectuadas sempre de
forma sncrona). Um cliente pode obter, a partir de outro cliente, uma cpia mais actualizada da base
de dados. Adicionalmente, possvel, a um cliente, delegar noutro um conjunto de reservas. Para que
o servidor possa vericar a validade da utilizao das reservas, a delegao de uma reserva sempre
acompanhada de um endosso assinado pelo cliente que possua a reserva esta informao (cadeia de
endossos) posteriormente propagada para o servidor quando a reserva utilizada.
7.2.3 Prottipo
Para validar a exequibilidade do modelo proposto, foi implementado um prottipo do sistema Mobsinap
na linguagem Java. O prottipo implementa as funcionalidades propostas no sistema atravs de uma
camada de sistema intermdia (middleware), organizada como descrito nesta seco.
Para permitir a utilizao de diferentes bases de dados no cliente e no servidor usou-se a aproxi-
mao descrita na seco 6.2.6. O sistema de comunicaes seguras foi criado recorrendo API de
segurana do Java. Inicialmente, recorreu-se implementao desta API efectuada pela Cryptix [31].
Os interpretadores de PL/SQL foram criados usando o programa de criao de analisadores gramaticais
JavaCC [169]. A implementao do mecanismo de execuo de mltiplas transaces usa parcialmente
o cdigo do sistema IceCube [134].
O servidor do sistema Mobisnap foi testado em computadores PCs com o sistema operativo Win-
dows 2000/XP e Linux. Os clientes foram testados em computadores PCs com vrias verses do sistema
operativo Windows e Linux e em computadores de bolso Compaq iPaq com o sistema operativo Sava-
jeOS [150]. No entanto, como so completamente implementados emJava (incluindo o sistema de gesto
de bases de dados usado), espera-se que corramemqualquer computador que possua uma implementao
do ambiente Java 2, standard edition.
7.3. TRANSACES MVEIS 111
7.3 Transaces mveis
As aplicaes modicam a base de dados atravs da submisso de transaces mveis. Uma transac-
o mvel um pequeno programa especicado num subconjunto da linguagem PL/SQL
3
[112]. No
apndice B.1 detalha-se o subconjunto da linguagem implementado no prottipo do sistema Mobisnap.
Relativamente linguagem PL/SQL foram introduzidas as seguintes modicaes: (1) as instrues
commit e rollback terminam a execuo de uma transaco mvel, i.e., actuam como uma instruo de
terminao; (2) quando o resultado de uma instruo select into inclui mais do que um registo, atri-
budo varivel o valor de um dos registos (em vez de lanar uma excepo); (3) foi introduzida a funo
newid cujo resultado o mesmo identicador nico quando executada no cliente e no servidor.
A execuo de uma transaco mvel (no cliente ou no servidor) corresponde sempre execuo do
seu programa usando um interpretador especial de PL/SQL. A execuo das vrias instrues de acesso
base de dados de uma transaco mvel so efectuadas no mbito de uma transaco denida no sistema
de gesto de bases de dados usado.
Em geral, uma transaco mvel corresponde a uma operao na aplicao que a submete por
exemplo, a reserva de um lugar num comboio ou a introduo de uma encomenda so exemplos tpicos
de operaes que podem ser submetidas como transaces mveis. Para cada operao, a aplicao deve
ter denido um esqueleto de transaco mvel. Este esqueleto instanciado com os valores especi-
cados pelos utilizadores, criando uma transaco mvel que ser submetida para execuo pelo sistema
Mobisnap. De seguida descreve-se o processamento de uma transaco mvel.
7.3.1 Processamento
Quando uma aplicao submete uma transaco mvel, o seu processamento consiste, em geral, nos
seguintes passos.
No cliente, a transaco executada de forma provisria e o seu resultado devolvido aplicao.
Se o cliente possui reservas suciente para garantir o resultado da transaco, este resultado pode ser
considerado denitivo. Em consequncia, ambas as verses da cpia local da base de dados so actua-
lizadas. Caso contrrio, o resultado provisrio. Neste caso, apenas a verso provisria actualizada.
O processamento de uma transaco mvel no cliente e a sua interaco com o sistema de reservas
detalhado na seco 8.3.
Aps ter sido executada localmente, uma transaco mvel armazenada de forma estvel no cliente.
Quando um cliente se conecta com o servidor, o cliente propaga as transaces mveis armazenadas para
3
O PL/SQL um linguagem imperativa denida pela Oracle que estende a linguagem SQL com um conjunto de estruturas
de caractersticas comuns s linguagens de alto nvel, como por exemplo a denio de tipos, constantes e variveis; instrues
de atribuio, de seleco (if ) e de repetio (loop,for,while).
o servidor. Em ambientes fracamente conectados, a propagao das transaces pode ser efectuada de
forma assncrona e incremental com uma semntica exactamente uma vez (exactly-once).
Quando um servidor recebe uma transaco mvel de um cliente, o servidor executa o programa da
transaco mvel na rplica principal dos dados para obter o seu resultado denitivo. Se a transaco foi
garantida no cliente, o modelo das reservas garante que no surgir nenhum conito inesperado durante
a execuo da transaco no servidor, como se detalha na seco 8.4.
Por vezes, a existncia de reservas concedidas a outros utilizadores pode levar a que uma transaco
mvel falhe desnecessariamente. Por exemplo, caso um cliente tenha reservado um lugar num comboio
(para garantir transaces de forma independente), o servidor garante que, pelo menos, um lugar perma-
nece disponvel. Assim, qualquer transaco de outro cliente que tente reservar o ltimo lugar disponvel
abortada. Caso o cliente no utilize o lugar reservado, pode ter existido uma transaco mvel que foi
abortada sem necessidade.
Para lidar com estas situaes, o Mobisnap inclui um mecanismo de reexecuo. As transaces
mveis abortadas no servidor podem ser reexecutadas aps as reservas relevantes expirarem ou serem
canceladas. Neste sentido, uma reserva pode ser vista como uma opo para modicar a base de da-
dos em primeiro lugar. As aplicaes devem indicar, quando submetem uma transaco mvel, se este
mecanismo deve ser usado e qual o prazo para a sua reexecuo nal.
Existem duas situaes em que necessrio executar um conjunto de transaces no servidor. Pri-
meiro, quando o cliente propaga um conjunto de transaces para o servidor. Segundo, quando um
conjunto de transaces aguarda a sua reexecuo no servidor. Nestas situaes, o servidor utiliza o
mecanismo de reconciliao descrito no captulo 10 para optimizar o conjunto de transaces no garan-
tidas no cliente que pode ser executado com sucesso (as transaces garantidas no cliente so executadas
imediatamente).
O sistema mantm informao sobre as transaces mveis que foram submetidas recentemente
para o servidor numa tabela do sistema (periodicamente, os registos mais antigos so removidos). Esta
informao consiste no resultado denitivo da transaco, no caso de este j ter sido determinado, ou
na indicao que aguarda reexecuo (nas situaes explicadas anteriormente). Esta informao permite
aos clientes obter o resultado das transaces submetidas em interaces anteriores.
7.3.2 Processamento alternativo
O modo de processamento tpico de uma transaco mvel, descrito anteriormente, pode ser alterado
atravs das seguintes opes especicadas aquando da submisso da transaco mvel:
Propaga sempre Uma transaco mvel sempre propagada para o servidor, independentemente do seu
resultado no cliente (por omisso as transaces que abortaram i.e., tiveram o resultado tentative
7.3. TRANSACES MVEIS 113
abort no so propagadas).
Garantido Se no for possvel garantir o resultado de uma transaco mvel no cliente, a transaco
imediatamente propagada para o servidor para execuo sncrona (no sendo executada proviso-
riamente no cliente). Se no for possvel contactar o servidor, o processamento prossegue como
habitualmente.
Servidor Se for possvel contactar o servidor, a transaco imediatamente propagada para o servidor
para execuo sncrona. Caso contrrio, o processamento prossegue como habitualmente.
Imediato Esta opo altera o comportamento das anteriores. Se no for possvel satisfazer imediata-
mente o processamento indicado, a transaco mvel abortada e o seu processamento con-
cludo.
Reexecuta Explicita que se pretende usar o mecanismo de reexecuo no servidor, caso a execuo
da transaco falhe. Um parmetro adicional dene o prazo limite para a execuo denitiva da
transaco (i.e., o ltimo momento em que possvel reexecutar a transaco mvel).
Melhor caminho Explicita que, quando apenas possvel garantir um resultado no ptimo no cliente,
se pretende que a execuo da transaco no servidor siga o melhor caminho possvel, mesmo que
diferente do caminho executado no cliente (ver detalhes no prximo captulo). No exemplo da
gura 7.1, pode aceitar-se, no servidor, a alternativa relativa ao produto BLUE THING mesmo que
no cliente apenas tenha sido possvel garantir a alternativa relativa ao produto RED THING.
Caminho garantido Explicita que, se no for possvel garantir o caminho de execuo no cliente, no
se deve tentar obter garantias sobre caminhos alternativos.
O processamento de uma transaco mvel no cliente e no servidor respeita as opes especicadas
pela aplicao aquando da sua submisso no cliente.
Neste captulo apresentou-se o modelo bsico do sistema Mobisnap, descrevendo-se a sua arquitec-
tura e o modo de processamento das transaces mveis. No prximo captulo detalha-se o sistema de
reservas proposto para prevenir a ocorrncia de conitos.
Captulo 8
Reservas
Neste captulo descreve-se o sistema de reservas do sistema Mobisnap. O objectivo das reservas permi-
tir ao sistema garantir o resultado de uma transaco mvel de forma independente. Para tal, necess-
rio garantir que no surgir nenhum conito quando o programa da transaco executado no servidor.
Assim, possvel garantir que uma transaco mvel tem o mesmo resultado e produz as mesmas mo-
dicaes no cliente e no servidor (ou modicaes equivalentes no contexto da aplicao). O sistema
de reservas do sistema Mobisnap desenhado com o objectivo de alcanar estes objectivos enquanto as
aplicaes continuam a usar as instrues usuais no PL/SQL. No cliente, o sistema verica automati-
camente a possibilidade de garantir o resultado de uma transaco a partir do programa da transaco
mvel.
8.1 Tipos de reservas
Uma reserva pode fornecer dois tipos de garantias para a execuo de uma transaco mvel no servidor.
Primeiro, uma garantia sobre o valor da base de dados. Assim, possvel garantir que o estado da base
de dados respeita as pr-condies para a execuo da transaco mvel. Segundo, uma garantia sobre
a exequibilidade de uma operao de modicao. Assim, garante-se que possvel executar as opera-
es da transaco mvel. De seguida, apresentam-se as reservas denidas no sistema Mobisnap
1
. Na
seco 8.5 apresentam-se exemplos que mostram a necessidade de combinar diferentes tipos de reservas
para garantir uma transaco mvel.
8.1.1 Reservas value-change e slot
Uma reserva value-change fornece o direito exclusivo de alterar um subconjunto de colunas num registo
j existente. Por exemplo, um utilizador pode reservar o direito de modicar a descrio do ocupante
1
Para nomear as reservas, usam-se os termos ingleses propostos em [126, 128].
115
116 CAPTULO 8. RESERVAS
de um lugar num comboio. Esta reserva semelhante a um trinco de escrita (write lock) de pequena
granularidade e inuencia as instrues SQL select e update.
Uma reserva slot fornece o direito exclusivo de inserir, remover ou modicar registos com valores
pr-determinados para algumas colunas. Por exemplo, um utilizador pode reservar o direito de alterar
uma agenda durante um dado perodo de tempo. Esta reserva semelhante a um trinco de predicado
(predicate lock) [60], incluindo registos existentes e no existentes. Esta reserva inuencia as instrues
SQL select, insert, delete e update.
Este tipo de reservas permite, no s, garantir a possibilidade de executar alteraes, mas tambm,
garantir que o estado da base de dados no servidor ser idntico ao observado no cliente. Assim, pode
ser visto como um mecanismo que permite mover a cpia principal de um subconjunto dos dados para
um computador mvel.
O uso deste tipo de reservas deve ser efectuado cuidadosamente, porque elas impedem outros uti-
lizadores de modicar os dados reservados. No entanto, se a granularidade das reservas obtidas pelos
utilizadores for adequada, estas reservas fornecem um mecanismo ecaz que contribui para o funciona-
mento correcto do sistema garantindo o resultado das transaces independentemente.
8.1.2 Reserva value-lock
Uma reserva value-lock garante que o valor de um subconjunto de colunas de um registo no ser mo-
dicado concorrentemente. Por exemplo, pode garantir-se que o identicador de um produto no
modicado. Esta reserva semelhante a um trinco de leitura (read lock) de pequena granularidade e
inuencia a instruo SQL select.
Este tipo de reservas apenas permite garantir que o estado da base de dados no servidor ser idntico
ao observado no cliente.
8.1.3 Reservas value-use
Uma reserva value-use permite a uma transaco mvel usar um dado valor para um dado elemento de
dados, independentemente do seu valor actual. A necessidade deste tipo de garantias comum na vida
real por exemplo, um vendedor ambulante pode garantir o preo de uma encomenda (igual ao preo
que ele conhece) independentemente de qualquer actualizao que tenha sido efectuada concorrente-
mente.
Uma transaco que use esta reserva observa o valor reservado no cliente e no servidor (as instrues
de leitura devolvem o valor reservado em vez do valor actual da base de dados).
8.1. TIPOS DE RESERVAS 117
8.1.4 Reservas escrow
Uma reserva escrow fornece o direito exclusivo de usar uma parte de um recurso divisvel representado
por um elemento de dados numrico. Por exemplo, a existncia de um produto (stock) pode ser dividido
entre vrios vendedores mveis. Esta reserva baseada no modelo de diviso (escrow) [111].
O modelo de diviso aplicado a elementos de dados numricos que representam recursos idnticos
2
e divisveis por exemplo, o nmero de CDs existentes num armazm, x. Para estes dados comum que
as seguintes propriedades sejam vlidas. Primeiro, eles so actualizados atravs da adio e subtraco
de constantes por exemplo, quando k CDs so vendidos, faz-se x x k. Segundo, necessrio
manter restries quanto aos valores que esses dados podem tomar por exemplo, a existncia mnima
de CDs min, ou seja x min.
Para estes elementos de dados (chamados elementos de dados fungveis) possvel dividir os recursos
disponveis por vrias rplicas por exemplo, pode dividir-se x em n partes x
i
, 1 i n, tal que x =x
i
.
Cada rplica tem associada uma restrio local que garante a validade da restrio global, x
i
min
i
:
min = min
i
. Cada rplica pode garantir independentemente o resultado das transaces que respeitam
as restries locais, i.e., possvel garantir o resultado de transaces que subtraiam at x
i
min
i
(valor
agregado relativo a todas as transaces garantidas na rplica i) a x
i
.
Exemplo: Seja dez o valor actual da existncia de CDs (x = 10) e dois o seu valor mnimo (x 2).
Usando o modelo de diviso (escrow) possvel dividir a existncia actual por duas rplicas por
exemplo, a primeira rplica pode car com seis CDs (x
1
= 6) e a segunda rplica com quatro CDs
(x
2
= 4). A restrio global deve tambm ser dividida entre as duas rplicas por exemplo, a existncia
mnima em cada rplica pode ser igual a um (x
1
1 x
2
1). A primeira (respectivamente segunda)
rplica pode garantir transaces que subtraiam at cinco (respectivamente trs) CDs existncia de CDs
(x
1
min
1
= 61 = 5 e x
2
min
2
= 41 = 3).
Discute-se agora a implementao do modelo de diviso no sistema Mobisnap. Para reconhecer
os aspectos envolvidos, considere-se a transaco mvel apresentada na gura 8.1, na qual se insere
uma nova encomenda submetida por um vendedor mvel. Nesta transaco possvel usar as tcnicas
de diviso para garantir a disponibilidade da existncia do produto. A transaco executa os seguintes
passos para actualizar a existncia do produto: (1) o valor actual lido e a validade da operao vericada
(linhas 3-4); (2) o valor do elemento de dados que representa a existncia actualizado para reectir a
operao executada (linha 5). Estes passos representam um padro na actualizao de elementos de
dados divisveis.
O primeiro aspecto a considerar consiste na garantia da validade da operao (passo 1). Para tal,
2
Na seco 8.5 mostra-se como possvel solucionar problemas com recursos no idnticos usando o sistema de reservas
por exemplo, a marcao de lugares num comboio.
1 -- ENCOMENDA DE PRODUTO: nome = "BLUE THING"; quantidade = 10; preo mximo = 50.00
2 BEGIN
3 SELECT price,stock INTO prd_price,prd_stock FROM products WHERE name=BLUE THING
4 IF prd_price <= 50.00 AND prd_stock >= 10 THEN -- Verifica a validade da operao
5 UPDATE products SET stock = prd_stock - 10 WHERE name = BLUE THING;
6 INSERT INTO orders VALUES (newid,Clt foo,BLUE THING,10,prd_price,to process);
8 COMMIT prd_price; -- Conclui a transaco e devolve informao sobre
9 END IF; -- a encomenda efectuada
10 ROLLBACK;
11 ON ROLLBACK NOTIFY( SMS, 351927435456, Encomenda impossvel...);
12 END;
Figura 8.1: Transaco mvel que especica uma nova encomenda submetida por um vendedor (o bloco
de declarao de variveis omitido).
comum usar uma instruo if que verique se a actualizao viola a restrio local. Para usar a mesma
condio sem nenhuma funo especial, necessrio que a mesma restrio seja imposta no cliente e no
servidor. Assim, o modelo de diviso, como denido anteriormente [90], no pode ser implementado
imediatamente porque usa diferentes restries em cada uma das rplicas.
No sistema Mobsinap, introduzimos a seguinte alterao ao modelo de diviso apresentado anterior-
mente: x : x min dividido em n partes x
i
: x
i
min x min = (x
i
min). Como anteriormente,
cada rplica pode garantir independentemente o resultado das transaces que respeitem as restries
locais. No entanto, usa-se a mesma restrio em todas as rplicas. Esta propriedade permite vericar a
validade de uma operao usando a mesma restrio global (ou, mesmo, usar condies mais restritivas).
Exemplo: Para obter as mesmas garantias que no exemplo anterior, usam-se os seguintes valores:
x
1
= 7, x
1
2 e x
2
= 5, x
2
2. A primeira (respectivamente segunda) rplica pode garantir transaces
que subtraiam at cinco (respectivamente trs) CDs da sua existncia (x
1
min = 72 = 5 e x
2
min =
52 = 3).
Seja x
1
a rplica no servidor e x
2
a rplica num cliente mvel. x
2
= 5, x
2
2 signica que o cliente
mvel reservou o direito de subtrair trs ao valor de x (i.e., pode garantir encomendas para trs CDs).
Neste caso, diz-se que o cliente mvel obteve uma reserva escrow para trs unidades de x. No servidor,
o valor de x actualizado (x
1
= 103 = 7) de forma a reectir as garantias obtidas pelo cliente. Assim,
nenhuma transaco de outros clientes pode usar os elementos reservados.
Em alternativa, o valor de x
2
pode ser visto como o menor valor de x quando a transaco mvel
executada no servidor (i.e., x x
2
). O valor de x
2
apenas pode ser usado para garantir condies que
usem um operador relacional semelhante ao da restrio. Por exemplo, a condio x 10 no pode ser
garantida pela reserva escrow x
2
=5, x
2
2 porque esta reserva no garante o valor mximo de x. O valor
de x
1
pode ser visto como a quantidade do recurso divisvel no reservado por nenhum cliente mvel (e
portanto disponvel para ser utilizado pelos outros clientes, incluindo os clientes legados).
O segundo aspecto a considerar consiste na actualizao dos elementos de dados fungveis. Em geral,
8.2. CONCESSO E GARANTIA DE RESPEITO PELAS RESERVAS 119
uma transaco mvel actualiza o seu valor atravs de uma instruo update. No sistema Mobisnap, o
sistema infere automaticamente a quantidade usada do recurso reservado a partir da instruo de update.
Como esperado, os recursos usados so consumidos da reserva escrow. As prximas transaces apenas
podem ser garantidas usando o remanescente dos recursos reservados.
Como se descreveu, esta aproximao completamente transparente para os programadores. Os
programadores escrevem as transaces mveis sem nenhuma referncia s reservas. Se o cliente possui
alguma reserva, o sistema usa-a automaticamente para tentar garantir o resultado das transaces. O
sistema mantm igualmente registo das reservas usadas de forma automtica.
O prottipo do sistema Mobisnap tem uma limitao: apenas possvel impor uma nica restrio
sobre cada elemento de dados fungvel (ou x min ou x max) antecipa-se que este seja o cenrio
mais comum. Para impor uma restrio min x max seria necessrio usar diferentes valores para x
i
dependendo do tipo de operao executada.
8.1.5 Reservas shared value-change e shared slot
Uma reserva shared value-change garante o direito partilhado de modicar o valor de um registo (ou
subconjunto de colunas de um registo). Por exemplo, esta reserva pode ser usada para garantir uma
operao de incremento sobre um contador partilhado. Esta reserva permite obter a garantia que uma
instruo update no ser bloqueada por uma reserva value-change, slot ou value-lock.
Uma reserva shared slot garante o direito partilhado de inserir, remover e modicar registos com
valores pr-denidos. Por exemplo, esta reserva pode ser usada para garantir operaes sobre tabelas a
que apenas possvel adicionar registos (append-only tables). Esta reserva garante que uma instruo de
insert, delete ou update no ser bloqueada por uma reserva value-change, slot ou value-lock.
Estas reservas no fornecem qualquer garantia sobre o estado futuro da base de dados. No entanto,
ao garantirem que nenhum cliente obtm uma reserva exclusiva que impossibilite a execuo de uma
operao, elas so importantes para garantir de forma completa uma transaco, como se exemplica na
seco 8.5.
8.2 Concesso e garantia de respeito pelas reservas
Nesta seco descreve-se o modo como as reservas so concedidas e como se garante o respeito pelas
reservas concedidas, i.e., como se garante que nenhuma transaco viola as garantias fornecidas por
uma reserva (incluindo as transaces executadas directamente na base de dados central pelos clientes
legados). Nas prximas seces descreve-se o processamento das transaces mveis no cliente e no
servidor quando se usam reservas.
vc vl s vu e shvc shs
value-change (vc) no no no sim no no no
value-lock (vl) no sim no sim no no no
slot (s) no no no sim no no no
value-use (vu) sim sim sim sim sim sim sim
escrow (e) no no no sim sim
no no
shared value-change (shvc) no no no sim no sim sim
shared slot (shs) no no no sim no sim sim
Sim, enquanto as reservas agregadas no violarem a restrio global.

Tabela 8.1: Tabela de compatibilidade das reservas.
Um cliente mvel requisita uma conjunto de reservas do servidor antes de se desconectar. Este
conjunto deve ser denido com base nas operaes que se espera serem efectuadas pelo utilizador at
prxima interaco com o servidor. A deduo de bons valores para este problema pode ser vista como
uma extenso do problema da replicao antecipada [91, 87] (onde os clientes devem obter cpias dos
dados que os utilizadores vo aceder). Como se referiu anteriormente, este problema est fora do mbito
desta dissertao e pode ser atacado usando tcnicas de previso [53].
Nas experincias apresentadas na seco 9.2 usou-se uma estratgia simples que adapta a previso
do comportamento futuro do cliente com base no comportamento vericado. Esta estratgia permite
obter bons resultado numa aplicao de suporte a uma fora de vendas mvel. A interface grca da
aplicao desenvolvida permite, adicionalmente, especicar as reservas que devem ser obtidas de forma
simples. Internamente as reservas so obtidas atravs de variantes da instruo select. Por exemplo,
para requisitar uma reserva escrow de trs unidades relativa ao produto com o identicador 3, o cliente
submete a instruo get escrow reservation stock instances 3 from products where id=5.
Quando umcliente solicita uma reserva, o servidor verica se possvel conceder a reserva. Primeiro,
o servidor verica se existe alguma reserva concedida que impossibilite a concesso da nova reserva. Para
tal, usa-se a tabela de compatibilidade apresentada na tabela 8.1, em que sim signica que possvel
conceder uma reserva de um dado tipo mesmo que j tenha sido concedida um reserva do outro tipo que
actue sobre o mesmo elemento de dados. Se os conjuntos de elementos de dados afectados por duas
reservas no se intersectarem, ambas podem ser concedidas.
Segundo, o servidor verica se o utilizador do cliente mvel pode obter a reserva requisitada. Esta
vericao efectuada com base em regras de autorizao especicadas pelo administrador do sistema.
Estas regras especicam que reservas cada utilizador pode obter e por quanto tempo podem ser conce-
didas. A composio destas regras [33] pode ser simples e esttica ou complexa recorrendo a funes
PL/SQL.
Quando uma reserva concedida, o sistema Mobisnap tem de garantir que a promessa que lhe est
8.2. CONCESSO E GARANTIA DE RESPEITO PELAS RESERVAS 121
associada no quebrada por nenhuma outra transaco. Para fazer cumprir estas promessas, ao mesmo
tempo que permite aos clientes legados aceder directamente base de dados central, as seguintes aces
tm de ser executadas na base de dados (note-se que estas aces so desfeitas para permitir a execuo
de uma transaco que use uma dada reserva):
Para cada reserva value-change, cria-se um gatilho (trigger) que impede a modicao do ele-
mento de dados reservado. O gatilho impede a modicao lanando uma excepo. Neste caso,
diz-se que a modicao foi bloqueada.
Para cada reserva value-lock, cria-se um gatilho que impede a modicao do elemento de dados
reservado por qualquer transaco, incluindo as transaco submetidas por um cliente que possua
essa reserva. Para tal, ao contrrio do que sucede com as outras reservas, esta aco no desfeita
para permitir a execuo de uma transaco recebida de um cliente que possui esta reserva.
Para cada reserva slot, cria-se um gatilho que impede qualquer transaco de inserir, remover ou
modicar registos com os valores referidos na reserva.
Para cada reserva escrow, actualiza-se o valor dos elementos de dados fungveis como explicado
na seco anterior.
Para as reservas value-use, shared slot e shared value-change no necessria qualquer aco na
base de dados.
Para as reservas value-change e slot existe um opo adicional que pode ser usada: o pedido de
reserva pode especicar uma actualizao temporria que reicta a impossibilidade de modicar o ele-
mento de dados reservado enquanto a reserva permanecer vlida. Por exemplo, considere-se um registo
que representa um lugar num comboio. Quando um cliente mvel obtm uma reserva value-change so-
bre esse registo, o pedido de reserva pode especicar que se modique para verdadeiro o valor da coluna
que indica se o lugar est ocupado. Esta modicao indica que as transaces no garantidas por esta
reserva no devem utilizar este lugar. Se apesar desta indicao, uma transaco tentar modicar o valor
do registo, a modicao ser bloqueada pelo gatilho criado aquando da concesso da reserva.
O sistema Mobisnap mantm registo de todas as reservas concedidas para vericar a possibilidade de
conceder uma nova reserva (face s reservas j existentes) e para vericar a validade da utilizao de uma
reserva para garantir uma transaco mvel. Quando uma reserva expira ou cancelada explicitamente
pelo cliente, as aces executadas para garantir que a reserva respeitada so desfeitas. As aces
relativas a uma reserva so igualmente desfeitas (de forma temporria) para permitir a execuo de uma
transaco mvel que use essa reserva.
Como foi dito anteriormente, uma reserva temporria (leased) [58], i.e., apenas vlida durante um
perodo limitado de tempo. Esta propriedade garante que as restries impostas s outras transaces,
para fazer cumprir a promessa associada a um reserva, no duram indenidamente, mesmo que o cliente
mvel, a quem a reserva foi concedida, seja destrudo ou que permanentemente desconectado. Outra
consequncia da durao limitada das reservas consiste no facto da garantia fornecida num cliente mvel
apenas ser vlida se a transaco mvel for propagada para o servidor antes que as reservas usadas
expirem.
8.3 Processamento das transaces mveis no cliente
Um cliente executa uma transaco mvel localmente em um ou dois passos, como se explica de seguida.
No primeiro passo, o cliente executa o programa da transaco para vericar se possvel garantir o
seu resultado usando as reservas disponveis. Este processo descrito mais tarde. Se for possvel garantir
a transaco mvel, so actualizadas ambas as verses da rplica local dos dados. O processamento
local da transaco termina, sendo a transaco mvel armazenada localmente at ser propagada para o
servidor. Caso contrrio, o sistema desfaz qualquer modicao executada base de dados (abortando a
transaco da base de dados na qual a transaco mvel foi executada) e prossegue para o segundo passo.
No segundo passo, o cliente executa o programa da transaco na verso provisria da rplica local
da base de dados. O resultado desta execuo considerado provisrio. Se o programa executa at uma
instruo commit ou executa at ao m do programa, o resultado tentative commit. Neste caso, as
modicaes produzidas reectem-se na rplica provisrio dos dados. Se o programa executa at uma
instruo rollback, o resultado tentative abort e qualquer modicao produzida desfeita.
Se, durante o processamento de uma transaco mvel (em ambos os passos), necessrio algum
elemento de dados no replicado localmente para prosseguir a avaliao da transaco (por exemplo,
a condio de uma instruo if usa o valor de uma coluna no replicada), a execuo abortada e o
resultado da execuo local unknown.
8.3.1 Vericao da possibilidade de garantir uma transaco mvel
Nesta subseco descreve-se o modo como o interpretador do cliente verica se uma transaco mvel
pode ser garantida. A ideia base consiste em executar o programa da transaco e vericar cada instruo
do caminho de execuo.
Garantir instrues Durante a execuo, o interpretador mantm, para cada varivel, alm do seu
valor actual, a informao sobre se esse valor garantido e quais as reservas que o garantem (se alguma).
8.3. PROCESSAMENTO DAS TRANSACES MVEIS NO CLIENTE 123
O valor de uma varivel garantido se foi atribudo numa instruo SQL de leitura garantida ou
numa instruo de atribuio que no inclua nenhuma varivel no garantida.
Uma instruo SQL pode ser garantida se: (1) todas as variveis usadas na instruo SQL (como
valores de entrada) so garantidas; (2) existe uma reserva que inclua os elementos de dados lidos ou
escritos, i.e., que tenha uma condio compatvel com a condio expressa na instruo SQL e inclua
a coluna indicada. Para vericar a segunda condio, necessrio comparar a descrio semntica da
reserva e a condio expressa na instruo SQL
3
.
As seguintes restries adicionais so aplicadas. Uma reserva value-use ou value-lock no pode
garantir uma instruo de escrita (update, insert, remove). Uma reserva partilhada (shared value-change
e shared slot) no pode garantir uma instruo de leitura (select).
Nas instrues de leitura , por vezes, apenas possvel obter uma garantia parcial do valor lido, i.e.,
a garantia que quando a transaco executada no servidor o valor lido se encontra num dado intervalo.
Por exemplo, se uma transaco mvel executa uma instruo de leitura que conte o nmero de registos
que satisfazem uma dada condio e o cliente detm apenas uma reserva value-change que satisfaa
a condio indicada, possvel garantir que, quando a instruo de leitura executada no servidor, o
resultado obtido maior ou igual a um. Esta garantia, semelhante obtida nas reservas escrow, pode
ser suciente para garantir o resultado da transaco mvel. Durante o processamento da transaco
mvel no cliente, a utilizao de uma varivel com este tipo de garantia est sujeita s mesmas restries
impostas s variveis garantidas por reservas escrow (explicadas anteriormente).
Quando se executa uma instruo de escrita SQL, ambas as verses da base de dados so actualizadas.
Uma instruo de leitura SQL garantida devolve o valor reservado. Uma instruo de leitura SQL no
garantida devolve o valor da verso provisria da base de dados.
Uma instruo if garantida se todas as variveis envolvidas na condio expressa so garantidas
e permitem garantir o resultado da condio. Como se explicou na seco 8.1, as variveis garantidas
por reservas escrow no podem ser usadas para garantir o valor exacto de uma varivel, mas apenas que
este valor se encontra num dado intervalo. Assim, apenas podem ser usadas para garantir o valor de
condies que exprimam relaes de ordem (<, , >, ).
Se a condio no pode ser garantida, assume-se que o seu valor falso, por omisso. Assim, pos-
svel garantir uma modicao alternativa (numa sequncia de modicaes alternativas guardadas por
instrues if ) quando no possvel garantir a opo preferida. Por exemplo, na transaco da gura 7.1,
o cliente pode apenas deter reservas sobre o produto RED THING. Neste caso, possvel garantir a
encomenda deste produto, mas impossvel garantir a opo preferida pelo utilizador (relativa ao pro-
duto BLUE THING). Quando a transaco mvel executada no servidor, por omisso, executa-se o
3
Aproximaes semelhantes so usadas na replicao secundria semntica [35] e na optimizao das interrogaes [4]).
mesmo caminho de execuo, mesmo que a alternativa preferida pelo utilizador seja possvel.
Uma aplicao pode modicar o processamento descrito usando as opes descritas na seco 7.3.2.
Primeiro, possvel abortar a execuo da transaco se uma condio no puder ser garantida. Segundo,
possvel solicitar a execuo do melhor caminho possvel no servidor, independentemente do caminho
garantido no cliente.
A aproximao usada para garantir as instrues if pode ser igualmente usada para garantir o valor
de outras condies, como por exemplo as condies especicadas nas instrues de ciclo.
Resultado da execuo Se um programa executa at uma instruo commit, o seu resultado reserva-
tion commit. Neste caso, diz-se que o resultado da transaco garantido independentemente no cliente.
No entanto, dependendo das instrues que foi possvel garantir, atribudo um dos seguintes nveis de
garantias:
Full (completo), se todas as instrues no caminho de execuo so garantidas por reservas. Note-
-se que, mesmo neste caso, incorrecto aplicar, no servidor, o conjunto de escrita (write set) obtido
aquando da execuo da transaco no cliente, porque os elementos de dados fungveis devem ser
actualizados usando instrues de adio e remoo.
Read (leitura), se for possvel garantir todas as instrues com excepo das instrues de escrita.
Neste caso (e nos seguintes), quando a transaco mvel executada no servidor, a execuo das
escritas no garantidas pode ser bloqueada por uma reserva value-change, value-lock ou slot.
Pre-condition (pr-condio), se possvel garantir todas as condies que determinam o caminho
de execuo. Neste caso, o sistema penas garante que a execuo do programa de uma transaco
seguir o mesmo caminho de execuo no servidor.
Alternative pre-condition (pr-condio alternativa), se, pelo menos, uma condio que determina
o caminho de execuo no foi garantida. Neste caso, a aplicao pode forar a execuo do
mesmo caminho de execuo ou no no servidor (como se explicou anteriormente).
Como se exemplica na seco 8.5, uma aplicao deve utilizar informao adicional (do domnio
da semntica da aplicao) para interpretar o signicado dos diferentes nveis de garantias. Por exemplo,
os nveis de garantia completo e leitura so equivalentes se se souber que impossvel obter uma reserva
que impea a execuo das instrues de escrita. Os resultados obtidos devem ser apresentados aos
utilizadores utilizando esta informao adicional conhecida.
Se um programa executa at uma instruo rollback, o sistema aborta a execuo, desfazendo todas
as modicaes efectuadas. O processamento da transaco mvel prossegue no segundo passo descrito
no incio desta seco.
8.4. PROCESSAMENTO DAS TRANSACES MVEIS NO SERVIDOR 125
Quando o resultado de uma transaco reservation commit, o cliente associa automaticamente a
informao sobre a execuo do programa (reservas usadas, caminho de execuo e valores lidos nas
instrues de leitura) com a transaco. O cliente propaga esta informao para o servidor, o qual a usa
durante a execuo da transaco.
8.4 Processamento das transaces mveis no servidor
A execuo de uma transaco mvel no servidor consiste na execuo do programa da transaco mvel
na base de dados central.
Transaco no garantida Se o resultado da transaco no foi garantido no cliente, o cdigo da
transaco deve fazer respeitar as intenes do utilizador atravs da especicao de regras de deteco
e tratamento de conitos apropriadas.
Durante a execuo de uma transaco mvel no servidor, as escritas bloqueadas por reservas podem
ser tratadas pela transaco (independentemente da transaco ter sido garantida no cliente ou no). Para
tal, o cdigo da transaco mvel deve apanhar a excepo lanada pelo gatilho que protege os elementos
de dados reservados. Caso a excepo lanada no seja tratada, a transaco abortada e as aplicaes
podem posteriormente vericar a causa do insucesso. As transaces abortadas podem ser reexecutadas
usando o mecanismo de reexecuo mencionado na seco 7.3.1.
Transaco garantida Se o resultado da transaco foi garantido no cliente, o interpretador que exe-
cuta o programa da transaco mvel deve executar o seguinte conjunto de aces adicionais (para que
as garantias fornecidas sejam respeitadas).
Antes de executar a transaco, para cada reserva usada para garantir o seu resultado no cliente,
necessrio desfazer temporariamente (at concluso da execuo da transaco) as aces que garantem
o respeito por essas reservas. Dois casos especiais existem. Para uma reserva escrow adicionado ou
subtrado ao valor actual dos dados a quantidade de recursos usados na execuo da transaco no cliente.
Como estas reservas so parcialmente consumidas com a execuo das transaces, nenhuma aco
executada no m do processamento da transaco. Para uma reserva value-use, o valor actual dos dados
substitudo pelo valor da reserva aps a execuo da transaco o valor inicial reposto.
Durante a execuo da transaco, para cada instruo de leitura garantida no cliente, o interpretador
devolve o valor relativo ao mesmo registo lido no cliente. Assim, esta propriedade estabelece uma ordem
no conjunto de resultados obtidos na execuo de uma instruo de leitura. No caso de a leitura ter sido
garantida por uma reserva value-use, value-change, value-lock ou slot, esta propriedade garante que o
mesmo valor obtido no cliente e no servidor.
Quando o nvel de garantia de uma transaco no cliente foi alternative pre-condition, o interpretador
deve garantir que o caminho de execuo respeita a opo especicada pela aplicao. Por omisso, o
interpretador executa o mesmo caminho independentemente do resultado das condies especicadas
nas instrues if. Como se referiu anteriormente, a aplicao pode forar a execuo do melhor caminho
possvel.
Aexecuo de uma transaco mvel consome parcialmente as reservas escrowusadas. Por exemplo,
se o cliente tinha uma reserva que lhe permitia subtrair trs unidades ao valor de uma varivel fungvel
e a transaco subtrai uma unidade, o cliente ca apenas com o direito de subtrair duas unidades a essa
varivel. Todas as outras reservas permanecem vlidas (at expirarem ou serem devolvidas).
Aps executar a transaco, o servidor refaz as aces necessrias ao respeito das reservas que per-
manecem vlidas.
8.5 Exemplos
Nesta seco apresentam-se exemplos da utilizao de reservas para garantir o resultado de transaces
mveis.
Recursos fungveis annimos A gura 8.1 representa uma operao tpica executada num sistema de
suporte a uma fora de vendas mvel: um pedido de encomenda. O pedido de encomenda satisfeito se
a existncia disponvel permite satisfazer o pedido e o preo do produto no superior ao preo mximo
que o comprador est disposto a pagar.
Na tabela 8.2 apresentam-se as reservas obtidas pelo vendedor mvel. Para cada reserva, mantm-se
a seguinte informao: o identicador nico da reserva, id; o tipo da reserva; as colunas reservadas
nos registos seleccionados na tabela pela condio; o valor do(s) elemento(s) reservado(s); informao
adicional especca para cada tipo de reserva (por exemplo, o tipo de restrio das reservas escrow);
informao de ligao com outra reserva; e data de expirao da reserva. A data de expirao permite
ao sistema no usar reservas que expirem antes do prximo contacto esperado com o servidor. A ligao
permite associar uma reserva a outra, de modo a que apenas seja possvel usar a primeira se se usar
tambm a segunda. Neste exemplo, a reserva value-use est ligada reserva escrow, de modo a que o
vendedor mvel apenas possa garantir o preo reservado (com a reserva value-use) para as unidades de
produto reservadas (com a reserva escrow).
Quando a transaco executada no cliente, bvio que as duas reservas so necessrias para garantir
o resultado da condio expressa na instruo if (linha 4). A reserva escrow garante que prd_stock 10
verdadeiro quando a transaco executada no servidor. Na verdade, a reserva mais geral e permite
garantir a subtraco de at quinze unidades ao valor de prd_stock com a restrio global prd_stock
clt

8.5. EXEMPLOS 127
id tipo tabela coluna condio valor informao ligao
45-1 escrow products stock name=BLUE THING 15 0 -
45-2 value-use products price name=BLUE THING 44.99 - yes - 45-1
Tabela 8.2: Reservas obtidas por um vendedor mvel para garantir encomendas (data de expirao omi-
tida).
1 ------ COMPRA 1 BILHETE: comboio = "London-Paris 10:00"; dia = 18-FEB-2002; preo mximo = 100.00
2 BEGIN
3 SELECT price, available INTO tkt_price, tkt_avail FROM trains
4 WHERE train=London-Paris 10:00 AND day=18-FEB-2002;
5 IF tkt_price <= 100.00 AND tkt_avail >= 1 THEN --Verifica disponibilidade de lugar e se preo aceitvel
6 UPDATE trains SET available = tkt_avail - 1 WHERE train = London-Paris 10:00 AND day = 18-FEB-2002;
7 -- Selecciona e reserva um lugar especfico para o comprador
8 SELECT seat INTO tkt_seat FROM tickets
9 WHERE train = London-Paris 10:00 AND day = 18-FEB-2002 AND used = FALSE;
10 UPDATE tickets SET used = TRUE, passenger = Mr. John Smith
11 WHERE train = London-Paris 10:00 AND day = 18-FEB-2002 AND seat = tkt_seat;
12 NOTIFY( SMTP, sal-07@thingco.pt, Bilhete reservado...);
13 COMMIT (tkt_seat,tkt_price); -- Conclui a transaco e devolve a informao
14 END IF; -- sobre o lugar reservado
15 ROLLBACK -1;
16 ON ROLLBACK NOTIFY( SMS, 351927435456, Impossvel adquirir bilhete ...);
17 END;
Figura 8.2: Transaco mvel para reservar um bilhete de comboio num sistema de reserva de bilhetes
(o bloco de declarao de variveis omitido).
0 (ou a promessa que quando a transaco executada no servidor, se tem prd_stock 15). A reserva
value-use garante que o preo aceitvel. A instruo update que actualiza a existncia do produto
(linha 5) garantida pela reserva escrow. Esta instruo usada para inferir a quantidade de recursos
fungveis utilizados. Neste caso, so usadas dez unidades, pelo que, aps a execuo da transaco,
o cliente apenas mantm reservadas cinco unidades este ser o novo valor da reserva escrow. A
instruo insert no garantida por nenhuma reserva. Assim, o resultado da transaco ser o nvel read
de reservation commit. Se a aplicao sabe que a insero na tabela orders no pode ser bloqueada,
possvel ter a certeza que a transaco executar com sucesso no servidor.
Para garantir o sucesso da instruo insert seria necessrio obter uma reserva adicional. Uma hip-
tese consiste em obter uma reserva shared slot para a tabela orders (as propriedades da funo newid
garantem a unicidade do identicador). Uma segunda hiptese consiste em adicionar uma coluna ta-
bela orders que especique o vendedor responsvel pela encomenda. Assim, obtendo uma reserva slot
para as encomendas introduzidas pelo prprio vendedor, seria possvel garantir a instruo insert.
Recursos fungveis no annimos A transaco mvel da gura 8.2 representa um exemplo tpico
da utilizao de recursos no annimos: a reserva de um lugar num comboio. Neste exemplo, cada
lugar nico e tem um identicador associado. Assim, aps vericar que existe, pelo menos, um lugar
disponvel (linha 5), necessrio obter o identicador do lugar (linha 8-9) e actualizar a informao do
tipo tabela coluna condio valor informao
escrow trains available train=London-Paris 10:00 2 0
value-use trains price AND 95.00 -
value-change tickets * day=18-FEB-2002 (4A, f alse, . . .) -
value-change tickets * (4B, f alse, . . .) -
Tabela 8.3: Reservas obtidas pelo garantir reservas de bilhetes de comboio (identicador, ligao e data
de expirao omitidos).
tipo tabela coluna condio valor
value-lock trainsids * true todos os registos
value-use trains price train=23 AND day=18-FEB-2002 95.00
value-change tickets * train=23 AND day=18-FEB-2002 (4A, f alse, . . .)
value-change tickets * train=23 AND day=18-FEB-2002 (4B, f alse, . . .)
Tabela 8.4: Reservas obtidas pelo garantir reservas de bilhetes de comboio: segunda alternativa (identi-
cador, ligao, informao e data de expirao omitidos).
nome do passageiro associada a esse lugar (linhas 10-11).
Vamos assumir que o cliente obteve reservas sobre dois lugares do comboio: as reservas respectivas
so apresentadas na tabela 8.3. O processamento da transaco mvel prossegue de forma similar ao
exemplo anterior at ser necessrio obter o identicador do lugar a usar. A instruo select (linhas 8-9),
que obtm o identicador do lugar, devolve um dos lugares reservados porque as instrues de leitura
devolvem preferencialmente valores reservados. Neste caso, poder-se-ia obter, por exemplo, o lugar
4A. A instruo update (linhas 10-11) actualiza a informao relativa ao lugar 4A com o nome do
passageiro e o preo do bilhete. Estas instrues so garantidas pela reserva value-change que o cliente
detm sobre o registo que mantm a informao do lugar 4A. Quando a transaco mvel executada
no servidor, o sistema garante que a instruo select devolve o mesmo registo, i.e., o registo relativo ao
lugar 4A. Assim, o resultado da transaco no cliente o nvel full de reservation commit (todas as
instrues so garantidas).
Se as reservas value-change no estivessem disponveis, seria impossvel garantir as instrues de
leitura e escrita relacionadas com o lugar (linhas 811). O resultado da instruo select seria obtido a
partir da verso provisria dos dados. Assim, o resultado da execuo local da transaco seria o nvel
pre-condition de reservation commit. Para esta transaco, este resultado signica que possvel garantir
a disponibilidade e preo do lugar, mas impossvel garantir o lugar que ser atribudo ao passageiro.
Na gura 8.3 apresenta-se uma verso alternativa para reservar um lugar num comboio. Neste exem-
plo, a base de dados mantm uma tabela que associa o nome do comboio com o seu identicador (um
inteiro). Adicionalmente, no existe informao sobre o nmero de lugares disponveis: este valor
obtido contando o nmero de lugares no ocupados.
Na tabela 8.4 apresentam-se as reservas obtidas para garantir dois lugares. Relativamente verso
8.5. EXEMPLOS 129
1 ------ COMPRA 1 BILHETE: comboio = "London-Paris 10:00"; dia = 18-FEB-2002; preo mximo = 100.00
2 BEGIN
3 SELECT id INTO train_id FROM trainsIds WHERE name = London-Paris 10:00;
4 SELECT price INTO tkt_price FROM trains WHERE train = train_id AND day=18-FEB-2002;
5 SELECT count(*) INTO tkt_avail FROM tickets WHERE train = train_id AND day=18-FEB-2002 AND used=FALSE;
6 IF tkt_price <= 100.00 AND tkt_avail >= 1 THEN --Verifica disponibilidade de lugar e se preo aceitvel
7 -- Selecciona e reserva um lugar especfico para o comprador
8 SELECT seat INTO tkt_seat FROM tickets
9 WHERE train = train_id AND day = 18-FEB-2002 AND used = FALSE;
10 UPDATE tickets SET used = TRUE, passenger = Mr. John Smith
11 WHERE train = train_id AND day = 18-FEB-2002 AND seat = tkt_seat;
12 NOTIFY( SMTP, sal-07@thingco.pt, Bilhete reservado...);
13 COMMIT (tkt_seat,tkt_price); -- Conclui a transaco e devolve a informao
14 END IF; -- sobre o lugar reservado
15 ROLLBACK -1;
16 ON ROLLBACK NOTIFY( SMS, 351927435456, Impossvel adquirir bilhete ...);
17 END;
Figura 8.3: Transaco mvel para reservar um bilhete de comboio num sistema de reserva de bilhetes:
segunda alternativa (o bloco de declarao de variveis omitido).
tipo tabela coluna condio valor
slot datebook * day=17-FEB-2002 AND hour 8 AND todos os registos que
hour 13 AND name = J. Smith satisfazem a condio
Tabela 8.5: Reservas obtidas sobre uma agenda partilhada para garantir novas marcaes (identicador,
ligao, informao e data de expirao omitidos).
anterior, obtm-se adicionalmente a reserva value-lock que permite garantir a converso efectuada entre
o nome do comboio e o seu identicador. Esta converso efectuada no incio da transaco mvel (linha
3). Como o valor obtido garantido pela reserva value-lock, a utilizao do identicador do comboio
no introduz nenhum problema para a possibilidade de garantir a transaco.
A segunda diferena em relao verso anterior consiste na inexistncia de um elemento de dados
com o nmero de lugares disponveis (sobre o qual se obtinha uma reserva escrow). Neste caso, a tran-
saco mvel conta o nmero de lugares no ocupados (linha 5). As reservas value-change permitem
garantir que, aquando da execuo da transaco mvel no servidor, existem, pelo menos, dois lugares
disponveis (uma garantia semelhante obtida anteriormente pela reserva escrow). Assim, possvel ga-
rantir o resultado da condio da instruo if (linha 7). O processamento da transaco mvel prossegue
de forma idntica verso anterior, permitindo obter como resultado o nvel full de reservation commit.
Agenda partilhada Neste exemplo, supe-se que existe uma agenda que mantm o conjunto de mar-
caes de demonstraes a efectuar pelos vendedores de uma empresa. Esta agenda pode ser modicado
por vrios utilizadores (por exemplo, os vendedores e as secretrias da empresa).
Na gura 8.4 apresenta-se uma operao tpica deste tipo de aplicao: a introduo de uma nova
marcao. Supe-se adicionalmente que o vendedor obteve uma reserva slot que lhe permite introduzir
marcaes em seu nome para a manh do dia 17 de Fevereiro, como descrito na tabela 8.5.
1 --- INSERE MARCAO: 16-FEB-2002 s 10:00 OU 17-FEB-2002 s 10:00, vendedor=J. Smith
2 BEGIN
3 id = newid; --- Primeira alternativa ------------------------------
4 SELECT count(*) INTO cnt FROM datebook WHERE day=16-FEB-2002 AND hour>=9 AND hour<12 AND user=J. Smith;
5 IF (cnt = 0) THEN --- Verifica disponibilidade
6 INSERT INTO datebook VALUES( id, 16-FEB-2002, 10, J. Smith, Demonstrao BLUE THING);
7 NOTIFY( SMS, 351927435456, Demonstrao marcada para 16-FEB-2002, 10:00);
8 COMMIT (16-FEB-2002,10); --- Conclui e devolve marcao
9 ENDIF; --- Segunda alternativa -------------------------------
10 SELECT count(*) INTO cnt FROM datebook WHERE day=17-FEB-2002 AND hour>=9 AND hour<12 AND user=J. Smith;
12 INSERT INTO datebook VALUES( id, 17-FEB-2002, 10, J. Smith, Demonstrao BLUE THING);
13 NOTIFY( SMS, 351927435456, Demonstrao marcada para 17-FEB-2002, 10:00);
14 COMMIT (17-FEB-2002,10); --- Conclui e devolve marcao
15 END IF;
16 ROLLBACK;
17 ON ROLLBACK NOTIFY( SMS, 351927435456, Marcao impossvel... );
18 END;
Figura 8.4: Transaco mvel que introduz uma nova marcao numa agenda partilhada (o bloco de
declarao de variveis omitido).
A reserva que o cliente possui no lhe permite garantir a instruo select referente ao dia 16 (linha
4). Assim, o resultado da condio da instruo if (linha 5) no pode ser garantido. Como se explicou
anteriormente, por omisso, durante a vericao da possibilidade de garantir o resultado de uma tran-
saco, considera-se que o resultado da condio falso. A execuo da transaco continua na linha
10. Neste caso, o resultado da instruo select garantido pela reserva slot que o cliente possui. Em
consequncia, possvel garantir o resultado da instruo if (linha 11). A instruo de insero (linha
12) igualmente garantida pela reserva slot. Assim, o resultado da transaco o nvel alternative pre-
-condition de reservation commit. Este resultado garante que a marcao ser efectuada, pelo menos,
para o dia 17.
Quando a transaco mvel executada no servidor, caso a aplicao tenha especicado a opo
melhor caminho, a marcao ser efectuada para o dia especicado em primeiro lugar (dia 16), caso tal
seja possvel. Se a aplicao no especicar essa opo, a transaco executar o mesmo caminho, sendo
introduzida a marcao garantida no cliente.
Os exemplos apresentados nesta seco mostram como as reservas so usadas para garantir o resul-
tado das transaces e o signicado dos diferentes nveis de garantias em face de diferentes transaces.
Adicionalmente, estes exemplos mostram que um sistema que pretenda fornecer garantias sobre dife-
rentes aplicaes necessita de fornecer diferentes tipos de garantias e que a combinao de diferentes
garantias , em geral, fundamental para garantir o resultado das transaces mveis no cliente. No
prximo captulo avalia-se quantitativamente a utilizao do sistema de reservas, assim como se ava-
lia qualitativamente a utilizao do sistema Mobisnap para suportar aplicaes de bases de dados num
ambiente de computao mvel.
Captulo 9
Avaliao do modelo bsico do sistema
Mobisnap
Osistema Mobisnap apresenta dois mecanismos principais: as transaces mveis e as reservas. Para que
o sistema possa suportar adequadamente o desenvolvimento de aplicaes para ambientes de computao
mvel, necessrio que os mecanismos propostos possam ser utilizados para responder aos requisitos de
mltiplos tipos de aplicaes. Este aspecto, de avaliao qualitativa do sistema, abordado na seco 9.1.
O sistema de reservas apenas permite conrmar o resultado de uma transaco mvel independente-
mente se o cliente mvel tiver obtido as reservas necessrias antes de car desconectado do servidor. Na
seco 9.2 apresenta-se um estudo sobre a eccia do sistema de reservas para uma aplicao de suporte
a uma fora de vendas mvel. Este estudo mostra que, no cenrio considerado, as reservas permitem
garantir o resultado de uma elevada percentagem de transaces mveis independentemente.
O sistema Mobisnap integra ainda um mecanismo de reconciliao de mltiplas transaces. Devido
ao seu carcter genrico, este mecanismo apresentado e discutido no prximo captulo.
9.1 Aplicaes
De seguida, descreve-se o modo como vrias aplicaes podem ser implementadas no sistema Mobisnap,
explorando os mecanismos existentes no sistema.
9.1.1 Suporte a uma fora de vendas
Uma aplicao de suporte a uma fora de vendas mantm informao sobre os produtos disponibilizados
por uma empresa. Esta aplicao deve permitir, a um vendedor mvel, executar as operaes necessrias
para satisfazer os pedidos dos clientes enquanto se encontra desconectado. As operaes mais comuns
que a aplicao deve suportar so as seguintes:
131
132 CAPTULO 9. AVALIAO DO MODELO BSICO DO SISTEMA MOBISNAP
1 ------ CANCELA ENCOMENDA: id = 3
2 BEGIN
3 SELECT status,product,qty INTO l_status,l_prod,l_qty FROM orders WHERE id = 3;
4 IF l_status = to process THEN
5 UPDATE orders SET status = cancelled WHERE id = 3;
6 UPDATE products SET stock = stock + l_qty WHERE id = l_prod;
7 COMMIT;
8 ELSE
9 ROLLBACK;
10 END IF;
11 END;
Figura 9.1: Transaco mvel que cancela uma encomenda introduzida anteriormente (o bloco de decla-
rao de variveis omitido).
1. acesso informao sobre os produtos e clientes;
2. submisso de uma nova encomenda;
3. cancelamento de uma encomenda submetida anteriormente.
Para permitir o acesso informao sobre produtos e clientes, o vendedor mvel obtm uma cpia
parcial da informao presente na base de dados central antes de se desconectar. Esta cpia parcial
deve incluir, pelo menos, informao sobre o subconjunto de clientes que o vendedor se prope visitar
e os produtos que esses clientes esto interessados. Na aplicao desenvolvida [32], os clientes e os
vendedores so agrupados em zonas geogrcas. A cpia parcial de cada vendedor inclui os clientes
da zona que ele visita e os produtos que eles encomendaram anteriormente. O vendedor tem ainda a
possibilidade de seleccionar dados adicionais para serem mantidos na sua cpia local.
Ovendedor executa as operaes de submisso e cancelamento de uma encomenda usando a interface
grca da aplicao. Na submisso de uma encomenda o vendedor especica o produto, quantidade
e preo mximo aceitvel para a encomenda. Adicionalmente, pode especicar valores alternativos
caso seja impossvel satisfazer o pedido do cliente. No cancelamento de uma encomenda, o vendedor
especica a encomenda aceite pelo sistema que deve ser cancelada.
As operaes executadas pelos vendedores so expressas como transaces mveis criadas pela apli-
cao. Para produtos fungveis, as transaces mveis das guras 7.1 e 9.1 exemplicam, respectiva-
mente, as operaes de submisso e cancelamento de uma encomenda. A transaco de cancelamento
obtm a informao sobre a encomenda a cancelar e, caso a encomenda ainda no tenha sido processada,
efectua as necessrias actualizaes. Para produtos no fungveis, a gura 8.2 exemplica a operao de
submisso de uma encomenda (o cancelamento de uma encomenda semelhante operao de cancela-
mento para produtos fungveis). Estas transaces exprimem a semntica dos pedidos efectuados pelos
clientes, vericando se possvel satisfazer as condies expressas. Adicionalmente, seria possvel re-
solver eventuais conitos indicando modicaes alternativas no cdigo das transaces mveis.
9.1. APLICAES 133
1 ------ REMOVE MARCAO: id=3476554
2 BEGIN
3 SELECT count(*) INTO cnt FROM datebook WHERE id = 3476554;
4 IF (cnt > 0) THEN
5 DELETE FROM datebook WHERE id = 3476554;
6 COMMIT;
7 END IF;
8 ROLLBACK;
9 END;
Figura 9.2: Transaco mvel que remove uma marcao numa agenda partilhada (o bloco de declarao
de variveis omitido).
O resultado da submisso de uma nova encomenda pode ser garantida usando reservas escrow, valu-
e-use e value-change como se descreveu na seco 8.5. Assim, os vendedores podem obter as reservas
necessrias para garantir as encomendas que esperam receber antes de se desconectarem (uma avaliao
da ecincia desta aproximao apresentada na seco 9.2). As reservas obtidas permitem garantir que
a encomenda pode ser satisfeita com a existncia do produto (stock) disponvel.
Na aplicao desenvolvida, o resultado do cancelamento de uma encomenda nunca garantida de
forma independente. Este facto resulta da deciso de permitir que o processamento das encomendas
possa ser iniciado em qualquer momento. Sem esta deciso, seria possvel garantir o cancelamento
de uma encomenda obtendo uma reserva value-change sobre o registo que descreve a encomenda. No
entanto, esta reserva impede o incio do processamento da encomenda no servidor porque no permite
que se actualize o seu estado.
A aplicao desenvolvida detalhada em [32]. A interface da aplicao foi desenvolvida usando
Java servlets [157]. A aplicao executa nos clientes mveis usando o servidor de servlets Jetty [106],
cuja reduzida dimenso se adequa s caractersticas dos dispositivos mveis.
9.1.2 Agenda partilhada
No mbito da aplicao de suporte a uma fora de vendas desenvolveu-se igualmente uma aplicao de
agenda partilhada. Esta aplicao permite gerir as demonstraes de produtos executadas pelos vendedo-
res. Assim, existe uma operao que introduz uma nova demonstrao (gura 8.4) e uma operaes que
remove uma demonstrao anteriormente marcada (gura 9.2). Estas operaes podem ser executadas
pelo vendedor ou pela secretaria da empresa.
possvel conrmar independentemente o resultado da introduo de novas marcaes usando re-
servas, como se explica na seco 8.5. Um vendedor pode tambm garantir o cancelamento das suas
marcaes obtendo reservas slot sobre os registos das suas marcaes.
9.1.3 Sistema de reserva de bilhetes de comboio
As operaes disponibilizadas num sistema de reserva de bilhetes de comboio so semelhantes s da
aplicao de suporte a uma fora de vendas na qual os produtos transaccionados no so fungveis. As-
sim, possvel usar a mesma aproximao para garantir operaes de forma independente em vrios
computadores, i.e., sem acesso ao servidor central. Esta aproximao permite, no s, ultrapassar situa-
es de desconexo com o servidor central, mas tambm, diminuir a latncia da execuo das operaes
e reduzir os picos de carga do servidor central, diferindo a execuo das operaes conrmadas indepen-
dentemente para momentos de carga mais reduzida.
A transaco que reserva um lugar num comboio foi apresentada na gura 8.2. A transaco que
cancela uma reserva pode ser denida de forma semelhante ao cancelamento de uma encomenda (com a
adicional libertao do lugar reservado). possvel garantir o resultado dos pedidos de reserva indepen-
dentemente usando reservas, como se explica na seco 8.5.
9.1.4 Metodologia de concepo das transaces mveis
As aplicaes anteriores exemplicam o modo como os mecanismos includos no sistema Mobisnap
podem ser usados para suportar a execuo durante perodos de desconexo.
Uma transaco mvel deve incluir a vericao das pr-condies de execuo da operao e, se
possvel, regras de resoluo de eventuais conitos. Assim, pretende-se garantir o respeito pelas inten-
es do utilizador e resolver os conitos que surjam de forma apropriada. Apesar desta aproximao
adicionar alguma complexidade denio de uma transaco mvel, os exemplos apresentados relati-
vos a vrias aplicaes mostram que simples criar uma transaco mvel. Aproximaes semelhantes
foram adoptadas anteriormente em vrios sistemas [161, 59], o que sugere que esta aproximao pode
ser facilmente utilizada num grande nmero de aplicaes.
As reservas permitem garantir independentemente o resultado das operaes e no introduzem com-
plexidade adicional na especicao das transaces mveis (porque a vericao da sua utilizao
transparente). Os exemplos anteriores mostram que as reservas existente so sucientes para garantir
o resultado de diferentes tipos de operaes. Adicionalmente, a pequena granularidade das reservas
permite obter reservas apenas sobre os elementos de dados necessrios, no impondo restries desne-
cessrias a operaes executadas sobre outros dados.
9.2 Reservas
Nesta seco apresenta-se uma estudo da ecincia do sistema de reservas no suporte a uma fora de
vendas mvel. A principal medida de ecincia usada a taxa de transaces conrmadas indepen-
9.2. RESERVAS 135
dentemente em diferentes cenrios de utilizao do sistema e usando diferentes polticas de distribuio
de reservas entre os clientes e os servidores. Os resultados obtidos mostram que possvel garantir o
resultado de uma elevada taxa de transaces de forma independente. Nos piores cenrios estudados,
este valor superior a 90% e 80%, quando, respectivamente, existe e no existe uma previso vel das
encomendas recebidas, tomando como referncia as transaces que podem ser aceites.
9.2.1 Modelo das experincias
As experincias apresentadas nesta seco simulam a utilizao de uma aplicao de suporte a uma fora
de vendas mvel, semelhante aplicao descrita na seco 9.1.1 ou a um sistema de reserva de lugares
(seco 9.1.3).
Esta aplicao mantm informao sobre um conjunto de produtos, incluindo, para cada produto, a
existncia (stock) disponvel e o preo. Os vendedores mveis usam um dispositivo porttil para subme-
ter as encomendas recebidas dos seus clientes. Estes pedidos so submetidos como transaces mveis
idnticas transaco mvel apresentada na gura 8.1. Para garantir o resultado dos pedidos de enco-
menda independentemente, os clientes obtm reservas escrow e value-use.
Nas experincias realizadas assume-se, sem perda de generalidade, que apenas existe um produto
disponvel e que o seu preo igual a um. Assim, o valor de uma encomenda igual ao nmero de
unidades encomendadas. Nestas experincias usa-se apenas um tipo de transaco mvel: a submisso
de uma nova encomenda. Como se explicou na seco 9.1.1, para garantir o cancelamento de uma en-
comenda seria necessrio restringir o seu processamento no servidor, o que no parece muito realista.
Adicionalmente, para garantir o cancelamento de uma encomenda seria necessrio que o cliente que
recebe a operao tivesse uma reserva value-change sobre essa encomenda. Assumindo que cada ven-
dedor obtinha este tipo de reservas sobre todas as encomendas que recebeu, seria possvel garantir todos
os pedidos de cancelamento recebidos pelo mesmo vendedor em que tinha sido efectuado o pedido de
encomenda.
As experincias efectuadas simulam a execuo do sistema Mobisnap, incluindo o servidor central,
um conjunto de clientes e o sistema de comunicaes. Os parmetros das experincias so apresentados
nas tabelas 9.1,9.2 e 9.3, que se explicam de seguida.
Cada experincia simula um perodo de doze horas. Os parmetros de falha do servidor, descritos na
tabela 9.1, levam a uma disponibilidade de 99, 7%.
Um mdulo de comunicaes simula as comunicaes entre os clientes e o servidor. Nas experin-
cias apresentadas modelam-se dois cenrios simples, descritos na tabela 9.1. O primeiro, MOV, modela
um ambiente de computao mvel no qual os clientes permanecem desconectados durante longos pe-
rodos de tempo. Neste cenrio, cada cliente ca impossibilitado de comunicar com o servidor durante
Nome mvel (MOV) distribudo (DIST)
Durao da experincia (t) 12 horas
Tempo entre falhas no servidor Exp(6 horas)
Durao das falhas no servidor Exp(1 min)
Tempo entre falhas na comunicao cliente/servidor Exp(2 horas)
Durao das falhas nas comunicaes cliente/servidor Exp(36 min) Exp(2 min)
Latncia de propagao das mensagens Exp(400 ms) Exp(200 ms)
Tabela 9.1: Parmetros das experincias: durao e falhas.
Nome pequeno (PEQ) grande (GRD)
Nmero de clientes 8 50
Existncia inicial (stock
init
) 300 30000
Quantidade em cada encomenda (valor da encomenda) round( 0.5 + Exp(1.5)) round( 0.5 + Exp(19.5))
Tabela 9.2: Parmetros das experincias: congurao do sistema simulado.
aproximadamente 30% do tempo. Esta impossibilidade modelada atravs de falhas na comunicao
entre o cliente e o servidor (injectando eventos de falha e recuperao na simulao). No entanto, podem
existir vrias causas para esta impossibilidade: desconexo voluntria, restries de energia, etc. A la-
tncia das comunicaes tem distribuio exponencial, modelando um tempo de comunicao varivel.
Uma mensagem com latncia superior a um segundo considerada perdida.
O segundo cenrio, DIST, modela um ambiente de computao distribuda. Cada cliente est impos-
sibilitado de comunicar com o servidor, em mdia, 1, 6% do tempo (o que est de acordo com estudos
recentes de conectividade em redes distribudas de larga escala [26, 120]).
Na tabela 9.2 descrevem-se as conguraes do sistema estudadas. A primeira, PEQ, simula uma
pequena fora de vendas mvel. Nesta congurao, existem apenas 8 clientes e a existncia inicial
igual a 300 unidades. A quantidade envolvida em cada encomenda varivel e baseada numa distribui-
o exponencial com valor mdio igual a duas unidades. Esta distribuio leva criao de encomendas
geralmente pequenas com um pequeno nmero de encomendas envolvendo grandes quantidades. A se-
gunda congurao, GRD, corresponde a um sistema com maior nmero de clientes, uma existncia
inicial e um valor mdio por encomenda mais elevados. Esta congurao usada para avaliar a inun-
cia da escala no comportamento do sistema.
Os pedidos de encomenda so gerados nos clientes, usando os parmetros descritos na tabela 9.3, da
Nome boa previso (BOM) m previso (MAU)
Taxa esperada de utilizao (e
u
) varivel
Fiabilidade da previso (sigma
base
) 0.04 0.64
Exactido da previso 10% em PEQ
face ao observado 5% em GRD 55%
Tabela 9.3: Parmetros das experincias: exactido das previses.
9.2. RESERVAS 137
seguinte forma. Primeiro, para cada experincia, a taxa esperada de utilizao, e
u
, controla o valor espe-
rado de todas as encomendas recebidas, exp
total
: exp
total
= e
u
stock
init
. Nas experincia apresentadas,
e
u
varia entre 55% e 175%, modelando desde uma procura reduzida at uma procura bastante forte.
Segundo, para cliente, gera-se um valor previsto de encomendas recebidas, exp
i
. exp
i
criado ale-
atoriamente de forma a que exp
total
= exp
i
. Na prtica, podem-se usar tcnicas de previso [53] para
obter este valor a partir da histria passada dos clientes.
Terceiro, gera-se, a partir do parmetro de abilidade da previso, sigma
base
, o valor real (esperado)
das encomendas recebidas em cada cliente, dem
i
. dem
i
obtido a partir de uma varivel aleatria com
distribuio normal (com valor_medio = exp
i
e sigma = sigma
base
exp
i
).
Finalmente, durante cada simulao, a submisso de cada pedido de encomenda controlado por
uma varivel aleatria com distribuio exponencial, como usual. O tempo mdio entre a submisso de
duas encomendas num cliente igual a t
req
avg
dem
i
, com req
avg
o valor mdio de cada encomenda. O modo
de criao dos pedidos leva a que, para cada cliente, o valor das encomendas recebidas possa diferir do
valor real, dem
i
.
Nas experincias realizadas, relativamente qualidade das previses, analisaram-se dois cenrios. O
primeiro, BOM, em que o valor previsto est muito prximo do valor observado. O segundo, MAU, em
que as previses so ms. Na tabela 9.3, mostra-se, para cada cenrio, a diferena mdia entre o valor
das encomendas criadas e o valor previsto (exp
i
).
Nas experincias realizadas avaliaram-se duas estratgias para obter reservas. Em ambas, os clientes
obtm reservas que expiram apenas no m da simulao. Na primeira estratgia, simp X, os clientes
obtm reservas apenas uma vez, no incio das experincia. X a fraco da existncia do produto que o
servidor reserva para si prprio (i.e., que os clientes no podem reservar). O resto da existncia reser-
vado pelos clientes (em conjunto com as reservas value-use), proporcionalmente ao valor de encomendas
previsto (exp
i
).
A segunda estratgia, din X, estende a primeira permitindo aos clientes obter reservas adicionais
quando as reservas que possuem j no permitem garantir uma encomenda de valor mdio. O servidor
concede reservas adicionais proporcionalmente s reservas obtidas anteriormente (de forma a que todos
os clientes tenham hiptese de obter reservas adicionais). Assim, um cliente i pode obter reservas adicio-
nais at (1X) (stock
init
used
n
)
used
i
used
n
unidades da existncia, com used
i
o nmero de unidades
reservadas anteriormente pelo cliente i.
Nas experincias apresentadas, as reservas so sempre obtidas a partir do servidor. Esta aproximao
difere de outros trabalhos [25] em que os algoritmos de redistribuio de recursos tangveis envolvem
mltiplos servidores. Este tipo de aproximao no parece apropriado aos ambientes de computao
mvel a que se destina o sistema Mobisnap, nos quais os computadores que integram o sistema podem
permanecer desconectados durante longos perodos de tempo, mas antes, a ambientes de computao
distribuda com boa conectividade entre os vrios servidores.
Para avaliar a ecincia do sistema de reserva obtiveram-se os seguintes resultados em cada experi-
ncia:
Fraco de encomendas (em valor) conrmadas independentemente nos clientes.
Fraco de encomendas (em valor) conrmadas independentemente nos clientes ou imediatamente
no servidor, i.e., encomendas que podem ser conrmadas com sucesso no servidor, caso exista
conectividade, usando a existncia do produto no reservada.
Como elemento de comparao, determinou-se, para cada experincia, o valor das encomendas que
podem ser executadas com sucesso num sistema cliente-servidor, em que o cliente executa imediata-
mente todas os pedidos de encomenda no servidor. Quando no possvel contactar o servidor aps
trs retransmisses, o cliente desiste de propagar a encomenda. Estes resultados so apresentados com a
legenda clt/srv.
Como o valor mximo das transaces que podem ser executadas com sucesso depende da taxa de
utilizao, obteve-se igualmente o valor mximo das transaces que podem ser executadas num sistema
distribudo perfeito em que nem os servidores nem as comunicaes falham e com latncia nula. Note-se
que, usando o mecanismo de reavaliao das transaces, sempre possvel obter este valor mximo
quando as reservas expiram (i.e., no m da simulao).
Cada experincia simula o comportamento do sistema durante um perodo de doze horas. Todos os
resultados apresentados so a mdia de dez simulaes. Quando se comparam diferentes aproximaes,
usam-se os mesmos eventos de gerao de encomendas.
9.2.2 Previso vel
Neste primeiro conjunto de experincias, avalia-se o cenrio em que as previses disponveis nos clientes
so boas. A diferena entre a previso de encomendas recebidas e o valor real observado , em mdia,
10% no cenrio pequeno, PEQ, e 5% no cenrio grande, GRD.
Por omisso, os resultados apresentados correspondem congurao com pequeno nmero de cli-
ente, PEQ, no ambiente computao mvel, MOV.
Conrmao independente dos resultados A gura 9.3 apresenta o valor das transaces que podem
ser conrmadas com sucesso nos clientes de forma independente em funo da taxa de utilizao. Os
valores apresentados so em percentagem do valor total de encomendas submetidas (grco da esquerda)
9.2. RESERVAS 139
50
55
60
65
70
75
80
85
90
95
100
55 70 85 100 115 130 145 160 175
C
o
m
m
i
t

(
%

t
o
t
a
l
)
Taxa de utilizao (%)
simp 0
simp 10
din 10
din 35
din 60
86
88
90
92
94
96
98
100
55 70 85 100 115 130 145 160 175
C
o
m
m
i
t

(
%

m
x
i
m
o
)
simp 0
simp 10
din 10
din 35
din 60
Figura 9.3: Transaces aceites localmente (cenrio MOV:PEQ:BOM): valor relativo ao total de enco-
mendas efectuadas (esquerda) e ao mximo possvel (direita).
50
55
60
65
70
75
80
85
90
95
100
55 70 85 100 115 130 145 160 175
C
o
m
m
i
t

(
%

t
o
t
a
l
)
simp 0
simp 10
din 10
din 35
din 60
88
90
92
94
96
98
100
55 70 85 100 115 130 145 160 175
C
o
m
m
i
t

(
%

m
x
i
m
o
)
simp 0
simp 10
din 10
din 35
din 60
Figura 9.4: Transaces aceites localmente (cenrio MOV:GRD:BOM): valor relativo ao total de enco-
e do valor mximo de encomendas que podem ser aceites num sistema cliente/servidor sem falhas (gr-
co da direita). Os resultados mostram que possvel conrmar localmente, de forma independente, o
sucesso de mais de 85% do mximo de encomendas que podem ser aceites, quer o cliente obtenha ou
no reservas adicionais durante a simulao.
Como se esperava, este valor diminui quando a taxa de utilizao aumenta e se aproxima de 100%.
Quando a taxa de utilizao inferior a 100%, cada cliente obtm reservas que excedem as necessidades
previstas. Estas reservas em excesso so usadas para conrmar encomendas no previstas.
Quando a taxa de utilizao superior a 100%, cada cliente apenas obtm reservas para um parte
das encomendas previstas. Assim, mesmo que as encomendas recebidas sejam inferiores s previstas, as
encomendas tendem a consumir todas as reservas que o cliente obtm. No entanto, ao contrrio do que
seria de esperar, os resultados da gura 9.3 no mostram nenhuma melhoria signicativa no valor das
transaces conrmadas localmente quando a taxa de utilizao superior a 100% (com excepo de
simp 0). O estudo desta situao permitiu concluir que este facto se deve ao modo como os servidores
satisfazem os pedidos de novas reservas. Assim, ao reservarem para si, em cada momento, uma fraco
da existncia disponvel, levam a que os clientes no consigam obter novas reservas (em nmero suci-
ente) quando a existncia disponvel escassa. Como esta situao apenas ocorre quando a existncia
50
55
60
65
70
75
80
85
90
95
100
55 70 85 100 115 130 145 160 175
C
o
m
m
i
t

(
%

t
o
t
a
l
)
simp 0
simp 10
din 10
din 35
din 60
86
88
90
92
94
96
98
100
55 70 85 100 115 130 145 160 175
C
o
m
m
i
t

(
%

m
x
i
m
o
)
simp 0
simp 10
din 10
din 35
din 60
Figura 9.5: Transaces aceites localmente (cenrio DIS:PEQ:BOM): valor relativo ao total de enco-
disponvel se aproxima de zero, ela afecta um nmero semelhante de encomendas independentemente da
existncia inicial. Quando o valor total das encomendas aumenta, o valor relativo deste efeito torna-se
desprezvel, como se pode observar na gura 9.4, relativa ao cenrio GRD. Os resultados apresenta-
dos mostram que, neste caso, quando a taxa de utilizao se afasta de 100%, o valor das transaces
conrmadas localmente aumenta para valores superiores a 99% do mximo possvel.
Quando os clientes apenas obtmreservas no incio da simulao, a existncia reservada pelo servidor
no pode ser usada para conrmar encomendas nos clientes. Este facto explica a diminuio da taxa de
conrmao local para valores inferiores a 90% em simp 10, quando a taxa de utilizao superior a
100%.
Os resultados das guras 9.3 e 9.4 mostram que a taxa de sucesso local diminui com o aumento da
fraco da existncia reservada pelo servidor. Quando os clientes obtm reservas adicionais, este facto
ca a dever-se a uma maior susceptibilidade dos clientes s falhas na rede, pela necessidade de contac-
tarem mais frequentemente o servidor. Os resultados relativos ao cenrio de computao distribuda,
apresentados na gura 9.5, corroboram esta explicao.
Conrmao imediata dos resultados Os resultados anteriores mostram que possvel conrmar in-
dependentemente nos clientes mais de 85% das encomendas submetidas. Quando se esgotam as reservas
que um cliente possui, ele pode conrmar imediatamente (mas no independentemente) o sucesso de
uma encomenda contactando o servidor, caso o servidor tenha reservado para si uma fraco da existn-
cia disponvel.
A gura 9.6 apresenta o valor das transaces que podem ser conrmadas com sucesso imediata-
mente nos clientes ou no servidor em funo da taxa de utilizao. Os resultados mostram que
possvel conrmar imediatamente o sucesso de mais de 95% das encomendas efectuadas. Este valor
aproxima-se de 100% quando a taxa de utilizao se afasta de 100%. Adicionalmente, e ao contrrio das
reservas aceites localmente (gura 9.3), observa-se que este valor aumenta com o aumento da fraco
9.2. RESERVAS 141
55
60
65
70
75
80
85
90
95
100
55 70 85 100 115 130 145 160 175
C
o
m
m
i
t

(
%

t
o
t
a
l
)
clt/srv
simp 0
simp 10
din 10
din 35
din 60
70
75
80
85
90
95
100
55 70 85 100 115 130 145 160 175
C
o
m
m
i
t

(
%

m
x
i
m
o
)
clt/srv
simp 0
simp 10
din 10
din 35
din 60
Figura 9.6: Transaces aceites imediatamente no cliente ou no servidor (cenrio MOV:PEQ:BOM):
valor relativo ao total de encomendas efectuadas (esquerda) e ao mximo possvel (direita).
55
60
65
70
75
80
85
90
95
100
55 70 85 100 115 130 145 160 175
C
o
m
m
i
t

(
%

t
o
t
a
l
)
clt/srv
simp 0
simp 10
din 10
din 35
din 60
93
94
95
96
97
98
99
100
55 70 85 100 115 130 145 160 175
C
o
m
m
i
t

(
%

m
x
i
m
o
)
clt/srv
simp 0
simp 10
din 10
din 35
din 60
Figura 9.7: Transaces aceites imediatamente no cliente ou no servidor (cenrio DIS:PEQ:BOM): valor
relativo ao total de encomendas efectuadas (esquerda) e ao mximo possvel (direita).
reservada pelo servidor (com excepo de din 60) simp 10 melhor que simp 0 e din 35 melhor que
din 10.
O valor das encomendas que podem ser aceites imediatamente num sistema cliente/servidor bas-
tante inferior e est directamente relacionado com o tempo de desconexo. Assim, no ambiente de
computao mvel MOV, em que o cliente permanece desconectado aproximadamente 30% do tempo, o
valor das transaces aceites imediatamente ligeiramente superior a 70% (este valor superior a 70%
porque o mecanismo de retransmisso de mensagens permite atenuar o efeito das falhas).
Ao contrrio do que seria de esperar, o valor das transaces cujo sucesso pode ser determinado
imediatamente no alcana 100%. Aps anlise das simulaes executadas observou-se que este facto se
devia a dois factores. Primeiro, quando a taxa de utilizao inferior a 100%, as falhas na rede levam
impossibilidade de contactar o servidor para conrmar algumas encomendas. Assim, quando as falhas na
rede so mnimas, possvel conrmar imediatamente o sucesso do mximo de encomendas possveis,
como se pode observar na gura 9.7, relativo a um ambiente de computao distribuda.
Segundo, quando a taxa de utilizao superior a 100%, os clientes obtm, por vezes, reservas que
no utilizam, quer porque no recebem mais encomendas, quer porque as reservas no so sucientes
para garantir as encomendas recebidas. Este facto consequncia do reduzido nmero de encomendas
55
60
65
70
75
80
85
90
95
100
55 70 85 100 115 130 145 160 175
C
o
m
m
i
t

(
%

t
o
t
a
l
)
clt/srv
simp 0
simp 10
din 10
din 35
din 60
65
70
75
80
85
90
95
100
55 70 85 100 115 130 145 160 175
C
o
m
m
i
t

(
%

m
x
i
m
o
)
clt/srv
simp 0
simp 10
din 10
din 35
din 60
Figura 9.8: Transaces aceites imediatamente no cliente ou no servidor (cenrio MOV:GRD:BOM):
valor relativo ao total de encomendas efectuadas (esquerda) e ao mximo possvel (direita).
0
10
20
30
40
50
60
55 70 85 100 115 130 145 160 175
M
e
n
s
a
g
e
n
s
din 10
din 35
din 60
0
100
200
300
400
500
600
700
800
55 70 85 100 115 130 145 160 175
M
e
n
s
a
g
e
n
s
din 10
din 35
din 60
Figura 9.9: Mensagens enviadas na obteno de novas reservas (cenrio MOV:PEQ:BOM esquerda e
MOV:GRD:BOM direita).
recebidas por alguns clientes. Quando cada cliente recebe, em mdia, um nmero mais elevado de
encomendas, estas situaes tendem a ser em menor nmero e a tornarem-se desprezveis, como se
observa na gura 9.8, relativo ao cenrio GRD num ambiente de computao mvel.
Mensagens de obteno de novas reservas Na gura 9.9 apresenta-se o nmero de mensagens pro-
pagadas na obteno de novas reservas. Este valor inclui todas as tentativas de propagao, pelo que o
envio de um pedido e a recepo da respectiva resposta contabilizado como duas mensagens, caso no
ocorra nenhum erro.
Os resultados mostram que o nmero de mensagens trocadas aumenta com a fraco da existncia
reservada pelo servidor. Este facto era esperado porque quanto maior o valor reservado pelo servidor,
menor o valor das reservas concedidas, em cada momento, pelo servidor.
Adicionalmente, o nmero de mensagens enviadas aumenta com o aumento da taxa de utilizao.
Este aumento tende a ser mais signicativo para valores prximos dos 100%. Estes factos so con-
sequncia da necessidade de obter mais reservas quando o nmero de encomendas aumenta e de o ser-
vidor conceder um menor nmero de reservas quando a existncia disponvel reduzida (o que apenas
acontece quando a taxa de utilizao se aproxima dos 100%).
9.2. RESERVAS 143
40
50
60
70
80
90
100
55 70 85 100 115 130 145 160 175
C
o
m
m
i
t

(
%

t
o
t
a
l
)
simp 0
simp 10
din 10
din 35
din 60
65
70
75
80
85
90
95
100
55 70 85 100 115 130 145 160 175
C
o
m
m
i
t

(
%

m
x
i
m
o
)
simp 0
simp 10
din 10
din 35
din 60
Figura 9.10: Transaces aceites localmente (cenrio MOV:PEQ:MAU): valor relativo ao total de enco-
Quando o servidor informa os clientes que no pode conceder reservas adicionais, os clientes no pe-
dem novas reservas. Contudo, os clientes vericam periodicamente (com um perodo longo dependente
das encomendas recebidas) se a situao de indisponibilidade se mantm. Este facto justica a quase
estagnao do nmero de mensagens trocadas quando a taxa de utilizao superior a 110%.
Os resultados apresentados mostram ainda que nmero de mensagens por encomenda recebida
superior quando a existncia mais reduzida. Este facto igualmente consequncia do menor valor das
reservas concedidas pelo servidor quando a existncia disponvel mais reduzida. No entanto, mesmo
no cenrio PEQ, o nmero de mensagens trocadas aceitvel. Por exemplo, em din 35, para uma taxa
de utilizao de 110% so enviadas 32 mensagens, correspondentes a 16 pedidos de novas reservas. Este
valor corresponde a uma mdia de 2 pedidos por cada cliente (incluindo os pedidos recusados e os que
falham devido a falhas na rede).
9.2.3 Previso no vel
Neste segundo conjunto de experincias, estuda-se o cenrio em que a previso das encomendas recebi-
das se afasta muito da realidade observada. A diferena entre a previso de encomendas recebidas e o
valor real observado , em mdia, 55%. Como anteriormente, os resultados apresentados correspondem
congurao com um pequeno nmero de clientes, PEQ, no ambiente de computao mvel, MOV,
caso no exista outra informao.
Conrmao independente dos resultados obtendo reservas inicialmente Na gura 9.10 apresenta-
-se o valor das transaces que podem ser conrmadas com sucesso nos clientes. Como seria de esperar,
os resultados so bastante piores do que quando a previso das encomendas recebidas vel. Neste
caso, os melhores resultados so obtidos quando os clientes obtm reservas adicionais durante a execu-
o da simulao. Por exemplo, quando o servidor reserva inicialmente 60% da existncia do produto,
possvel garantir com sucesso mais de 85% do mximo de encomendas possveis.
45
50
55
60
65
70
75
80
85
90
95
100
55 70 85 100 115 130 145 160 175
C
o
m
m
i
t

(
%

t
o
t
a
l
)
clt/srv
simp 0
simp 10
din 10
din 35
din 60
70
75
80
85
90
95
100
55 70 85 100 115 130 145 160 175
C
o
m
m
i
t

(
%

m
x
i
m
o
)
clt/srv
simp 0
simp 10
din 10
din 35
din 60
Figura 9.11: Transaces aceites imediatamente no cliente ou no servidor localmente (cenrio
MOV:PEQ:MAU): valor relativo ao total de encomendas efectuadas (esquerda) e ao mximo possvel
(direita).
55
60
65
70
75
80
85
55 70 85 100 115 130 145 160 175
C
o
m
m
i
t

(
%

t
o
t
a
l
)
din 10
din 35
din 60
80
81
82
83
84
85
86
87
88
89
55 70 85 100 115 130 145 160 175
C
o
m
m
i
t

(
%

m
x
i
m
o
)
din 10
din 35
din 60
Figura 9.12: Transaces aceites localmente quando os clientes no obtm inicialmente nenhuma reserva
(cenrio MOV:PEQ:MAU): valor relativo ao total de encomendas efectuadas (esquerda) e ao mximo
possvel (direita).
Quando a taxa de utilizao pequena, a fraco das encomendas conrmadas localmente muito
elevada. Por exemplo, para uma taxa de utilizao de 55%, possvel conrmar localmente mais de 95%
das encomendas quando se obtm reservas adicionais. Este facto consequncia do excesso de oferta
face procura.
Conrmao imediata dos resultados obtendo reservas inicialmente Na gura 9.11 apresenta-se o
valor das transaces que podem ser conrmadas imediatamente num cliente ou no servidor. Ao con-
trrio do esperado, estes resultados mostram apenas uma ligeira melhoria relativamente ao resultado das
transaces conrmadas localmente nos clientes. Analisando as experincias efectuadas foi possvel des-
cobrir que este facto se deve s reservas obtidas inicialmente, as quais so feitas com base em previses
que se vericam ser incorrectas.
Conrmao independente dos resultados no obtendo reservas inicialmente Para eliminar a in-
uncia negativa das previses incorrectas no sistema de reservas, estudou-se o comportamento do sis-
tema usando a estratgia de obteno dinmica de reservas, din X, no obtendo inicialmente nenhuma
9.2. RESERVAS 145
50
55
60
65
70
75
80
85
90
95
55 70 85 100 115 130 145 160 175
C
o
m
m
i
t

(
%

t
o
t
a
l
)
din 10
din 35
din 60
90
91
92
93
94
95
96
97
98
99
100
55 70 85 100 115 130 145 160 175
C
o
m
m
i
t

(
%

m
x
i
m
o
)
din 10
din 35
din 60
Figura 9.13: Transaces aceites localmente quando os clientes no obtm inicialmente nenhuma reserva
(cenrio MOV:GRD:MAU): valor relativo ao total de encomendas efectuadas (esquerda) e ao mximo
possvel (direita).
60
65
70
75
80
85
90
95
55 70 85 100 115 130 145 160 175
C
o
m
m
i
t

(
%

t
o
t
a
l
)
clt/srv
din 10
din 35
din 60
70
75
80
85
90
95
100
55 70 85 100 115 130 145 160 175
C
o
m
m
i
t

(
%

m
x
i
m
o
)
clt/srv
din 10
din 35
din 60
Figura 9.14: Transaces aceites imediatamente no cliente ou no servidor quando os clientes no obtm
inicialmente nenhuma reserva (cenrio MOV:PEQ:MAU): valor relativo ao mximo possvel (direita).
reserva (esta situao pode ser usada igualmente nos cenrios em que no existem previses). Assim,
um cliente apenas obtm reservas aps receber a primeira encomenda.
A gura 9.12 apresenta o valor das transaces que podem ser conrmadas com sucesso nos clientes
de forma independente em funo da taxa de utilizao, quando os clientes no obtm reservas no incio
da simulao. Os resultados mostram que, neste caso, possvel conrmar entre 80% e 90% das enco-
mendas recebidas. Como o sistema se adapta procura dinamicamente, impossvel conrmar algumas
das primeiras encomendas recebidas em cada cliente. Este facto explica o aumento da fraco de tran-
saces conrmadas localmente com o aumento da taxa de utilizao (e, em consequncia, do valor das
transaces).
Os resultados obtidos quando a existncia inicial maior (cenrio GRD), apresentados na gura 9.13,
corroboram a explicao anterior. Adicionalmente, estes resultados mostram que a aproximao adop-
tada permite que o sistema de reservas se adapte s necessidades de cada cliente, permitindo conrmar
localmente mais de 90% das transaces possveis (para taxas de utilizao superiores a 100%, este valor
sobe para valores superiores a 97%).
5
10
15
20
25
30
35
40
45
50
55
55 70 85 100 115 130 145 160 175
M
e
n
s
a
g
e
n
s
din 10
din 35
din 60
0
100
200
300
400
500
600
700
55 70 85 100 115 130 145 160 175
M
e
n
s
a
g
e
n
s
din 10
din 35
din 60
Figura 9.15: Mensagens enviadas na obteno de novas reservas quando o cliente obtm inicialmente o
mximo de reservas possveis (cenrio MOV : PEQ : MAU esquerda e MOV : GRD : MAU direita).
10
15
20
25
30
35
40
45
50
55
55 70 85 100 115 130 145 160 175
M
e
n
s
a
g
e
n
s
din 10
din 35
din 60
100
200
300
400
500
600
700
800
900
55 70 85 100 115 130 145 160 175
M
e
n
s
a
g
e
n
s
din 10
din 35
din 60
Figura 9.16: Mensagens enviadas na obteno de novas reservas quando o cliente no obtm reservas no
incio da simulao (cenrio MOV : PEQ : MAU esquerda e MOV : GRD : MAU direita).
Conrmao imediata dos resultados no obtendo reservas inicialmente A gura 9.14 mostra as
transaces que podem ser imediatamente conrmadas no cliente ou no servidor. Como se esperava,
os resultados obtidos so melhores do que quando o cliente obtm inicialmente reservas. Neste caso,
possvel conrmar imediatamente o sucesso de mais de 95% das encomendas recebidas.
Mensagens de obteno de novas reservas Na gura 9.15 apresenta-se o nmero de mensagens pro-
pagadas na obteno de novas reservas quando o cliente obtm o mximo de reservas inicialmente.
Como anteriormente, este valor inclui todas as tentativas de propagao, pelo que o envio de um pedido
e a recepo da respectiva resposta contabilizado como duas mensagens. Como se esperava, os resulta-
dos obtidos so muito semelhantes aos apresentados quando a previso das reservas necessrias vel
porque este valor est directamente relacionado com a existncia disponvel para a obteno de novas
reservas.
Na gura 9.16 apresenta-se o nmero de mensagens propagadas quando o cliente no obtm reservas
inicialmente. Os resultados obtidos mostram que o nmero de mensagens enviadas tende a ser ligeira-
mente superior situao anterior (em que os clientes obtm reservas no incio da simulao com base na
previso das necessidades). No entanto, mesmo nesta situao, os custos de comunicaes so pequenos.
9.2. RESERVAS 147
Por exemplo, no cenrio PEQ, com a estratgia de obteno de reservas din 60 (respectivamente din 10)
e uma taxa de utilizao de 110% (respectivamente 90%), os clientes obtm reservas a partir do servidor
uma vez por cada 7, 3 (respectivamente 12, 7) encomendas recebidas no cliente. Estes valores so muito
superiores no cenrio GRD.
Os resultados apresentados mostram que o sistema de reservas permite suportar uma aplicao de su-
porte a uma fora de vendas mvel quando possvel estimar a procura em cada cliente e mesmo quando
no possvel fazer esta previso. Neste caso, necessrio usar estratgias dinmicas de obteno de
reservas. As estratgias usadas nestas experincias apresentam uma boa adaptao s necessidades dos
clientes com custos de comunicao aceitveis.
Captulo 10
Sistema de reconciliao SqlIceCube
Neste captulo descreve-se o sistema SqlIceCube [133]. O SqlIceCube um sistema genrico de reconci-
liao para transaces mveis. Este sistema explora a semntica das operaes para criar uma sequncia
de execuo que permita maximizar o nmero (ou valor) de transaces mveis que podem ser execu-
tadas. A informao semntica necessria ao funcionamento do sistema extrada automaticamente do
cdigo das transaces mveis.
No sistema Mobisnap, o SqlIceCube usado para executar um conjunto de transaces mveis nas
seguintes situaes: (1) quando se executam as transaces mveis no garantidas recebidas de um
cliente; (2) quando se executa o conjunto de transaces que aguardam reexecuo aps o cancelamento
ou expirao de uma reserva.
O sistema SqlIceCube um sistema genrico de reconciliao que estende o sistema IceCube apre-
sentado em [134]. Como um sistema genrico, inclui algumas funcionalidades que no so exploradas
no sistema Mobisnap. No entanto, de forma a apresentar o sistema de forma completa, descrevem-se
todas as caractersticas do sistema SqlIceCube neste captulo.
10.1 Modelo geral
O sistema SqlIceCube um sistema de reconciliao que aborda o processo de reconciliao como
um problema de optimizao, aproximao da qual foi pioneiro o sistema IceCube [85]. Assim, este
sistema tenta criar a sequncia de execuo que permite optimizar o conjunto de transaces mveis
que podem ser executadas com sucesso combinando os conjuntos de transaces mveis executadas
concorrentemente.
Considere-se o exemplo da gura 10.1, no qual dois utilizadores modicaram concorrentemente uma
agenda partilhada. Um utilizador requisita a sala A s 9:00 e tambm a sala B ou C igualmente s 9:00.
Outro utilizador requisita a sala Aou Bs 9:00. Se as operaes do primeiro utilizador fossemexecutadas
149
150 CAPTULO 10. SISTEMA DE RECONCILIAO SQLICECUBE

9:00 sala A
ou
9:00 sala B
9:00 sala A
9:00 sala B
ou
9:00 sala C
Log 1 Log 2
9:00 sala A
9:00 sala A
ou
9:00 sala B
Reconciliao
9:00 sala B
ou
9:00 sala C

Figura 10.1: Ordenao de um conjunto de operaes executadas concorrentemente.
antes da operao do segundo utilizador, a sala A e B seriam reservadas para o primeiro utilizador e a
operao do segundo utilizador falharia (considerando que no caso de haver mltiplas alternativas se
escolhia a primeira possvel). Uma situao semelhante acontece se a operao do segundo utilizador for
executada em primeiro lugar. A primeira operao do primeiro utilizador falha porque a sala A j est
reservada. No entanto, a ordem apresentada na gura permite a execuo de todas as operaes.
O exemplo anterior mostra que, em algumas situaes, possvel obter um melhor resultado de
reconciliao atravs da reordenao das operaes mesmo quando as operaes apresentam regras de
resoluo de conitos. Neste exemplo, no seria possvel explorar as alternativas para obter o melhor
resultado da reconciliao sem reordenar as operaes. A generalidade dos sistemas de reconciliao
genricos (por exemplo, no sistema Bayou [161] e Deno [82]) no reordenam as operaes.
Como, para qualquer conjunto no trivial de transaces, impossvel testar todas as sequncias de
execuo possveis, o sistema executa uma pesquisa heurstica dirigida usando a informao semntica
sobre as transaces a reconciliar. Esta informao denida sobre a forma de relaes que condicionam
a ordenao e exequibilidade das operaes. O sistema extrai esta informao automaticamente a partir
do cdigo das transaces mveis.
O SqlIceCube uma extenso do sistema IceCube apresentado em [134]. Relativamente a esse
sistema foram introduzidas duas mudanas fundamentais. Primeiro, ao contrrio do sistema IceCube,
a reconciliao vista como um problema de planeamento em vez de um problema de resoluo de
restries (binrias). Esta aproximao permite a execuo de duas transaces incompatveis entre si,
desde que, depois de executar a primeira transaco, se execute uma nova transaco que torne possvel
a segunda transaco. Segundo, o sistema SqlIceCube inclui um mecanismo de extraco automtica
de relaes entre as transaces mveis. Desta forma, os programadores no necessitam de expor esta
informao explicitamente. Finalmente, foram introduzidas algumas alteraes para adaptar os algorit-
mos de reconciliao ao modelo de execuo das transaces (mais simples) e s (diferentes) relaes
semnticas extradas.
10.2. RELAES ESTTICAS 151
10.2 Relaes estticas
O sistema SqlIceCube usa informao semntica expressa como relaes entre pares de transaces
mveis. As relaes denidas tm uma natureza esttica, sendo vlidas independentemente do estado da
base de dados. Estas relaes podem codicar a semntica das aplicaes (relaes da aplicao) ou a
semntica dos dados (relaes dos dados).
10.2.1 Relaes da aplicao
Uma relao da aplicao (log contraints) dene uma dependncia esttica entre duas transaces exe-
cutadas num mesmo uxo de actividade, i.e., numa mesma sesso de uma aplicao. Estas relaes
so independentes da semntica de cada transaco mvel e exprimem as intenes dos utilizadores,
codicando a semntica das macro-operaes denidas por um conjunto de transaces mveis.
Foram denidas as seguintes relaes da aplicao:
Predecessor/sucessor Estabelece que o sucessor apenas pode ser executado aps a execuo com su-
cesso do predecessor. Esta relao til quando o predecessor produz algum efeito usado pelo
sucessor.
Predecessor/sucessor fraco Estabelece que, se as duas transaces forem executadas com sucesso, o
predecessor deve ser executado antes do sucessor. Esta relao permite estabelecer a ordem de
execuo entre duas aces.
Alternativas Dene um conjunto de transaces das quais apenas uma deve ser executada. A especi-
cao de alternativas um mecanismo simples de resoluo de conitos.
Grupo indivisvel Dene um conjunto de transaces, as quais devem ser todas ou nenhuma executada
com sucesso.
Em geral, estas relaes, por exprimirem as intenes dos utilizadores, so expressas explicitamente
pela aplicao ao submeter as transaces mveis. No entanto, como se discute na seco 10.5.4.3, o
sistema de extraco automtica de relaes consegue inferir algumas destas relaes a partir do cdigo
das transaces. Por exemplo, uma transaco que especique vrias opes como uma sequncia de
instrues if pode ser dividida num conjunto ordenado de transaces alternativas.
No prottipo do sistema Mobisnap, apenas se usam as relaes da aplicao inferidas automatica-
mente. No entanto, seria simples introduzir uma nova operao na API do sistema que permitisse s
aplicaes adicionar relaes da aplicao entre as vrias transaces mveis submetidas no cliente.
10.2.2 Relaes dos dados
As relaes dos dados (data contraints) exprimem relaes, entre duas transaces, que reectem a
semntica das operaes e dos dados, independentemente do estado da base de dados.
Foram denidas as seguintes relaes:
Comutativas Indica que duas transaces so comutativas, i.e., que o resultado da sua execuo idn-
tico independentemente da ordem de execuo (se executadas consecutivamente). Duas transac-
es t
1
e t
2
so comutativas sse s S, t
1
(t
2
(s)) =t
2
(t
1
(s)), com S o conjunto de todos os estados
possveis da base de dados, e t(s) o estado da base de dados que resulta de executar a transaco t
no estado s.
Impossibilita Indica que uma transaco torna impossvel a execuo (sucessiva) de outra transaco.
t
1
impossibilita t
2
sse s S, valido(t
2
, t
1
(s)), com valido(t, s) verdadeiro sse possvel executar
com sucesso a transaco t no estado s. Por exemplo, uma transaco que reserve um dado lugar
num comboio impossibilita a execuo com sucesso de outra transaco que reserve o mesmo
lugar.
Torna possvel Indica que uma transaco torna possvel a execuo (sucessiva) de outra transaco.
t
1
torna possvel t
2
sse s S, valido(t
2
, t
1
(s)). Por exemplo, uma transaco que cancele uma
reserva de um dado lugar num comboio possibilita a execuo com sucesso de outra transaco
que reserve o mesmo lugar.
Desfavorece Indica que uma transaco desfavorece a execuo (sucessiva) de outra transaco. t
1
desfavorece t
2
sse s S : valido(t
2
, s) valido(t
2
, t
1
(s)). Por exemplo, uma transaco que
aumente o preo de um produto desfavorece a possibilidade de se executar uma transaco cujo
preo a usar tenha um limite mximo.
Favorece Indica que uma transaco favorece a execuo (sucessiva) de outra transaco. t
1
favorece
t
2
sse s S, valido(t
2
, s) valido(t
2
, t
1
(s)). Por exemplo, uma transaco que reduza o preo
de um produto favorece a possibilidade de se executar uma transaco cujo preo a usar tenha um
limite mximo.
Estas relaes so extradas automaticamente a partir do cdigo das transaces mveis como se
explica na seco 10.5.
10.2.3 Transaces independentes
Com base nas relaes anteriores, deniu-se a relao de independncia entre duas transaces. Duas
transaces dizem-se independentes se a execuo de uma transaco no puder inuenciar a execuo
10.3. ALGORITMO DE RECONCILIAO 153
de outra transaco. Se duas transaces forem independentes, a ordem pela qual so executadas no
inuencia o resultado nal. Face s relaes denidas anteriormente, as transaces a e b so indepen-
dentes sse:
independentes(a, b) =predecessor/sucessor(a, b) predecessor/sucessor(b, a)
predecessor/sucessor f raco(a, b) predecessor/sucessor f raco(b, a)
comutativas(a, b)
10.3 Algoritmo de reconciliao
O algoritmo de reconciliao dene a ordem de execuo das transaces na base de dados. O espao de
solues possveis explorado por amostragem de forma heurstica. Para tal, sucessivas solues so cri-
adas e executadas at que uma soluo satisfatria seja encontrada. Cada soluo gerada independente
das anteriores, i.e., no se usa uma aproximao de optimizao local.
Uma soluo inclui apenas as transaces executadas com sucesso. As restantes transaces podem
ter sido excludas da soluo por no poderem ser executadas no estado nal da base de dados ou por vi-
olarem uma relao esttica (por exemplo, pertencer a um conjunto de alternativas, do qual foi executada
uma transaco).
Acada transaco pode ser atribudo umvalor numrico que representa a sua importncia no contexto
da aplicao (no sistema Mobisnap, assume-se que todas as transaces tem valor igual a um). A soma
dos valores numricos das transaces includas numa sequncia representa o valor da soluo o
sistema SqlIceCube tenta criar uma sequncia de transaces que maximize este valor.
Para melhorar o desempenho do sistema de reconciliao decompe-se a criao da sequncia de
execuo em vrios subproblemas. Cada subproblema consiste em criar uma parte da sequncia a partir
de um subconjunto de transaces independentes do resto das transaces. Nesta seco detalham-se os
algoritmos usados no sistema de reconciliao.
10.3.1 Heurstica
Uma soluo (sequncia de execuo) criada incrementalmente seleccionando em cada passo uma
transaco para execuo. Esta seleco efectuada, aleatoriamente, entre as transaces com mrito
mais elevado.
O mrito associado a uma transaco estimado, de forma heurstica, a partir das relaes estticas
que se estabelecem entre as transaces. Nesta estimativa, apenas so consideradas as transaces que
podem ser executadas. O mrito de uma transaco que no pode ser executada imediatamente por as
relaes da aplicao estabelecidas no estarem satisfeitas (por exemplo, uma transaco que sucessora
de outra transaco ainda no executada) tem mrito nulo.
O mrito de uma transaco estima o benefcio de adicionar essa transaco soluo parcialmente
construda. Este mrito deve ser tanto menor quanto maior for o valor das transaces que no podem ser
executadas no futuro devido execuo desta transaco. Mais precisamente, o mrito de uma transaco
t tanto maior quanto (por ordem decrescente de importncia e considerando apenas as transaces que
ainda podem ser executadas com sucesso):
1. Maior for o nmero de transaces j executadas que pertencem ao mesmo grupo indivisvel (por-
que a execuo de apenas um subconjunto das transaco de um grupo indivisvel leva a uma
sequncia de execuo invlida).
2. Menor for o valor das transaces que apenas podem ser executadas antes de t (porque todas as
transaces predecessores tm de ser abortadas) relao predecessor/sucessor fraco.
3. Menor for o valor das transaces que so alternativas a t (porque dados dois conjuntos de tran-
saces alternativas entre si, mais provvel conseguir executar uma transaco do conjunto com
mais alternativas) relao alternativas.
4. Menor for o valor das transaces que t torna impossveis (porque essas transaces no podem
ser executadas, pelo menos, enquanto no for executada uma transaco que torne a sua execuo
possvel outra vez) relao impossibilita. Maior for o valor das transaces que t torna possveis
relao torna possvel.
5. Maior for o valor das transaces que so sucessoras (fracas ou fortes) de t (porque a execuo do
predecessor torna possvel a execuo do sucessor) relao predecessor/sucessor fraco e prede-
cessor/sucessor.
6. Menor for o valor das transaces que t desfavorece (porque menor ser a probabilidade de exe-
cutar essa transaces com sucesso) relao favorece. Maior for o valor das transaces que t
favorece relao desfavorece.
Independentemente das regras anteriores, o mrito de uma transaco innitamente baixo se: (1)
for sucessora (forte) de uma transaco ainda no executada (relao predecessor/sucessor); (2) for pre-
decessora (fraca) de uma transaco j executada (relao predecessor/sucessor fraco); (3) for alternativa
de uma transaco j executada.
10.3.2 Algoritmo bsico
O algoritmo de reconciliao implementado apresentado nas guras 10.3 e 10.2. A funo criaUma-
Soluo cria uma soluo e a funo reconcilia implementa o algoritmo de reconciliao completo.
reconcilia ( bd, trxs) =
melhorValor := 0
melhorSoluo := []
sumrio := computaSumrio( trxs) // Cria informao auxiliar
DO
bd.initTrx() // Prepara criao de nova soluo
{ soluo, valor } := criaUmaSoluo (bd, sumrio, trxs)
IF melhorSoluo( bd, soluo, valor) THEN // Verifica se a melhor soluo
melhorSoluo := soluo // Guarda a melhor soluo
melhorValor := valor
END IF
bd.rollbackTrx()
UNTIL termina ( melhorSoluo, melhorValor)
bd.initTrx() // Repe estado da melhor soluo
bd.executa( melhorSoluo)
bd.commitTrx()
RETURN { melhorSoluo, melhorValor }
Figura 10.2: Algoritmo de reconciliao (sem parties)
Inicialmente, a funo reconcilia calcula um sumrio das relaes denidas entre as transaces
(computaSumrio). Este sumrio usado para estimar o mrito de cada transaco ecientemente. O
algoritmo de reconciliao prossegue com a criao de sucessivas solues (criaUmaSoluo) de forma
provisria. A melhor soluo guardada. Os critrio que denem se uma dada soluo a melhor at
ao momento (melhorSoluo) e se o algoritmo deve terminar (termina) podem ser denidos de forma
especca em cada sistema. Por omisso, o valor da soluo usado para determinar se uma soluo a
melhor at ao momento, e o algoritmo executa durante um perodo pr-denido de tempo (ou at todas
as transaces poderem ser executadas com sucesso). Quando o algoritmo termina, a melhor soluo
encontrada executada de forma denitiva na base de dados
1
.
A funo criaUmaSoluo cria uma soluo e executa-a na base de dados de forma incremental. Du-
rante a execuo do algoritmo, as transaces a reconciliar so agrupadas nos seguintes subconjuntos:
(1) transaces j executadas com sucesso; (2) transaces impossveis de executar devido execu-
o de uma transaco j includa na soluo (relaes alternativas e predecessor/sucessor fraco); (3)
transaces impossveis de executar temporariamente (relao impossibilita e transaces que aborta-
ram aquando da execuo); (4) transaces candidatas execuo (todas as transaces no includas
em nenhum dos outros conjuntos). Esta informao mantida juntamente com o sumrio das relaes
existentes entre as transaces.
Ociclo principal consiste na sucessiva seleco e execuo de uma nova transaco
2
. Esta transaco
seleccionada de entre as transaces candidatas usando a heurstica apresentada anteriormente.
1
A seguinte optimizao foi implementada: se o ciclo de pesquisa de novas solues terminar imediatamente aps ser criada
a melhor soluo, esta soluo no chega a ser desfeita.
2
Para permitir desfazer no s uma transaco, mas tambm uma sequncia de transaces, necessrio que o sistema de
bases de dados suporte um mecanismo de transaces encaixadas (nested transactions) ou de pontos de gravao intermdios
no mbito de uma transaco (savepoints), como o existente na base de dados Oracle 8 usada no servidor do sistema Mobisnap.
criaUmaSoluo ( bd, sumrio, trxs) = // pseudo-cdigo
soluo := []
valor := 0
REPEAT
sumrio.reinicia( trxs)
WHILE sumrio.algumaPossvel() DO // Cria soluo incrementalmente
prxTrx := seleccionaPorMrito ( sumrio) // Selecciona aco a executar
dynOK := bd.executaInnerTrx( prxTrx)
IF dynOK = FALSE THEN // Resultado: rollback
sumrio.excluiTmp( prxTrx)
ELSE // Resultado: commit
soluo := [soluo|prxTrx] // Actualiza soluo
valor := valor + prxTrx.valor
sumrio.executada( prxTrx)
aExcluir := incompatveis( prxTrx, trxs) // Actualiza informao sobre transaces
sumrio.exclui( aExcluir)
aExcluirTmp := tornaImp( prxTrx)
sumrio.excluiTmp( aExcluirTmp)
aIncluirTmp := tornaPosAjuda( prxTrx)
sumrio.incluiTmp( aIncluirTmp)
END IF
END WHILE
gtrxs = gruposIncompletos(trxs,soluo) // Transaces pertencentes a grupos indivsiveis
trxs = trxs \ gtrxs // parcialmente executados
IF( NOT vazio(gtrxs)) THEN
bd.rollbackTrx()
bd.initTrx()
END IF
UNTIL vazio(gtrxs)
RETURN { soluo, valor}
Figura 10.3: Algoritmo de criao de uma nica soluo.
Se a execuo da transaco seleccionada aborta, a transaco passa a ser considerada temporaria-
mente impossvel de executar. Se uma transaco executada com sucesso, ela adicionada soluo
parcialmente construda. A informao sobre as transaces a executar actualizada. As transaces que
so incompatveis com a execuo dessa transaco (relaes alternativas e predecessor/sucessor fraco)
so adicionadas ao conjunto das transaces impossveis (assim como todas as transaces que perten-
am a um grupo indivisvel com uma das transaces impossveis). As transaces que so impossibili-
tadas (relao impossibilita) so adicionadas ao conjunto das transaces temporariamente impossveis.
As transaces que so beneciadas (relaes torna possvel e favorece) so removidas do conjunto das
transaces temporariamente impossveis. Em ambos os casos, o ciclo itera enquanto existem transac-
es candidatas com mrito no nulo.
Quando se conclui a criao de uma soluo necessrio vericar se a soluo vlida face s
relaes estabelecidas
3
. Para tal, necessrio vericar se existe algum grupo indivisvel parcialmente
executado (todas as outras relaes so necessariamente satisfeitas porque nunca se selecciona uma tran-
saco cuja execuo viole uma relao esttica com uma transaco anteriormente executada). Em
3
Uma optimizao implementada no prottipo do sistema consiste na vericao, sempre que uma transaco declarada
impossvel, da impossibilidade de executar completamente qualquer grupo indivisvel com transaces j executadas. Neste
caso, a soluo que se est a criar declarada imediatamente invlida.
reconciliaComParties ( bd, trxs) =
parties := particiona( trxs) // Divide em parties
soluo := []
valor := 0
FOR EACH part IN parties // Obtm soluo para cada partio
{ soluoParcial, valorParcial } := reconcilia ( bd, part.trxs)
soluo := [ soluo | soluoParcial ]
valor := valor + valorParcial
END FOR
RETURN { soluo, valor }
Figura 10.4: Algoritmo de reconciliao (com parties).
caso armativo, a soluo invlida e necessrio criar uma nova soluo. Para evitar cair numa situ-
ao semelhante na prxima soluo criada, o grupo de transaces parcialmente executado excludo
(temporariamente) do conjunto de transaces a reconciliar. Apesar desta aproximao poder levar a
uma soluo sub-ptima, garante que sempre possvel obter uma soluo (porque se vo excluindo os
grupos de transaces que causam problemas).
Durante a execuo do algoritmo criada uma explicao da razo pela qual cada transaco no foi
includa na soluo nal (omitido nos algoritmos apresentados). Esta informao pode ser usada pelas
funes melhorSoluo e termina ou para fornecer informao aos utilizadores.
10.3.3 Complexidade
Acomplexidade temporal esperada da funo criaUmaSoluo O(n
2
), comn o nmero de transaces a
reconciliar. Intuitivamente, o ciclo principal executado O(n) vezes (O(n) transaces so seleccionadas
para execuo). A complexidade do ciclo principal dominado pela funo de seleco (seleccionaPor-
Mrito) que analisa o mrito de todas as transaces candidatas. Esta funo executa em O(n) porque
o mrito de cada transaco avaliado em tempo constante usando o sumrio das relaes entre as
transaces. O tempo esperado de actualizao do sumrio constante (no caso esperado, a execuo de
uma transaco inuencia apenas um pequeno nmero de transaces). No pior caso, estas actualizaes
executam igualmente em O(n).
A complexidade de criao do sumrio (computaSumrio) O(n
2
) porque cada par de transaces
comparado para obter as relaes existentes entre elas. O ciclo de criao de solues igualmente
executado em O(n
2
) (no caso esperado, apenas um nmero reduzido de solues so criadas). Assim, a
complexidade total (esperada) do algoritmo de reconciliao (reconcilia) O(n
2
).
Atravs da utilizao de uma estrutura de dados especialmente adaptada manuteno do mrito
de cada transaco (baseado na utilizao de las de prioridade - priority queues) possvel reduzir a
complexidade da funo criaUmaSoluo para O(n.logn). No entanto, a complexidade global mantm-se
em O(n
2
) devido funo computaSumrio.
10.4 Optimizao da reconciliao
Nesta seco apresentam-se dois mecanismos que permitem melhorar o desempenho do sistema de re-
conciliao desenvolvido. Como a complexidade do algoritmo de reconciliao O(n
2
), possvel
melhorar o desempenho dividindo um problema de reconciliao numa sequncia de subproblemas de
menores dimenses (seco 10.4.1) e diminuindo o nmero de elementos envolvidos na reconciliao
(seco 10.4.2). Estes mecanismos foram propostos anteriormente no mbito do sistema IceCube [134].
10.4.1 Parties
Usando a noo de independncia de transaces, denida anteriormente, possvel dividir o problema
da reconciliao num conjunto de subproblemas. Para tal, divide-se o conjunto de transaces a recon-
ciliar em subconjuntos disjuntos mutuamente independentes, a que se chamam parties. O resultado da
reconciliao do conjunto original de transaces equivalente ao resultado da reconciliao sucessiva
de cada uma das parties.
Na gura 10.4 apresenta-se o algoritmo de reconciliao usando parties. A reconciliao exe-
cutada incrementalmente, invocando sequencialmente o algoritmo de reconciliao bsico (reconcilia)
para cada partio. A funo particiona divide o conjunto de transaces original, trxs, em k parties
de acordo com a seguinte relao:
trxs = p
1
p
2
. . . p
k
: i, j, i = j p
i
p
j
= / 0
a p
i
, b p
j
, independentes(a, b) alternativas(a, b) grupo_indivisivel(a, b)
O ciclo que executa a reconciliao sucessiva das vrias parties tem complexidade O(|p
1
|
2
+. . . +
|p
k
|
2
). Quando as parties tm dimenses idnticas, o tempo de execuo do ciclo tende a crescer
linearmente com o nmero de parties. Quando uma partio muito maior do que as outras, o tempo
de execuo do ciclo tende a ser dominado pela maior partio.
No entanto, a complexidade do algoritmo de reconciliao igualmente inuenciada pela algoritmo
de diviso em parties. Um algoritmo que use a relao anterior de forma imediata tem complexidade
O(n
2
) porque uma transaco tem de ser comparada com todas as outras. Assim, para melhorar o desem-
penho, efectua-se inicialmente uma diviso imprecisa usando um algoritmo de complexidade esperada
O(n). Neste algoritmo, cada transaco dene um conjunto arbitrrio de identicadores (por exemplo,
os nomes das tabela acedidas e/ou identicadores para as condies dos registos acedidos). As transac-
es com identicadores idnticos so includas na mesma partio. Para cada uma das parties ento
aplicado o algoritmo de partio exacto. A complexidade global ento O(n+|pi
1
|
2
+. . . +|pi
i
|
2
), com
pi
1
, . . . , pi
i
as parties criadas pelo algoritmo de diviso imprecisa.
10.4. OPTIMIZAO DA RECONCILIAO 159
Note-se que, em muitos casos, possvel executar a diviso em parties de forma incremental
e antes do momento da reconciliao (o que permite diminuir o tempo de execuo do algoritmo de
reconciliao). No sistema Mobisnap, a diviso em parties pode ser efectuada: nos clientes, para
o conjunto de transaces no garantidas a propagar para o servidor; no servidor, para o conjunto de
transaces a reexecutar quando uma reserva expira. Esta diviso pode ser efectuada incrementalmente
quando uma nova transaco adicionada aos conjuntos anteriores.
10.4.2 Compresso de uma sequncia de transaces
Duas sequncias de transaces dizem-se equivalentes se, quando executadas num qualquer estado da
base de dados, produzem o mesmo efeito (i.e., t
0
, t
1
, . . . , t
n
s
0
, s
1
, . . . , s
p
db, t
n
(. . . (t
1
(t
0
(db))))
s
p
(. . . (s
1
(s
0
(db))))). Um mecanismo de compresso de um registo de transaces transforma uma
sequncia de transaces numa sequncia de transaces equivalente com menor nmero de elemen-
tos (eliminando as transaces cuja execuo no produz efeitos no estado nal da base de dados).
De seguida descreve-se o mecanismo genrico de compresso de uma sequncia de transaces (ou
operaes). Este mecanismo usado, no sistema SqlIceCube, para comprimir a sequncia de transaces
a reconciliar submetida por cada utilizador, e no sistema DOORS, para comprimir a sequncia de invo-
caes executadas num coobjecto por uma aplicao. Este mecanismo usa as seguintes propriedades,
denidas entre pares de transaces, a e b:
b absorve a sse a execuo de b esconde os efeitos da execuo de a, i.e., s S, b(a(s)) = b(s).
Neste caso, [a, b] [b].
b compensa a sse os efeitos da execuo de a so compensados pela execuo de b, i.e., s
S, b(a(s)) = s. Neste caso, [a, b] [].
c comprime [a, b] sse a execuo de c comprime os efeitos da execuo sucessiva de [a, b], i.e., s
S, b(a(s)) = c(s). Neste caso, [a, b] [c] (esta propriedade no usada no sistema SqlIceCube).
Estas propriedades podem ser usadas para comprimir apenas pares de transaces que possam ser
executadas consecutivamente (logo, no se podem comprimir duas transaces alternativas entre si).
Caso contrrio, o resultado de uma transaco que deva ser executada entre ambas pode ser afectado.
Verica-se a possibilidade de executar duas transaces consecutivamente usando as seguintes regras de
reordenao
4
:
4
O mecanismo de compresso de sequncias de operaes implementado no sistema DOORS utiliza adicionalmente a
funo de transformao de operaes [159], transforma denida pelos programadores, tal que, trans f orma([a, b]) = [b
a
, a
b
] :
s, b(a(s)) a
b
(b
a
(s)). Neste caso [a, b] [b
a
, a
b
].
[a, t
0
, t
1
, . . . , t
n
, b] [a, b, t
0
, t
1
, . . . , t
n
], sse independentes(t
0
, b) . . . independentes(t
n
, b);
[a, t
0
, t
1
, . . . , t
n
, b] [t
0
, t
1
, . . . , t
n
, a, b], sse independentes(a, t
0
) . . . independentes(a, t
n
).
Adicionalmente, necessrio garantir que as intenes dos utilizadores expressas atravs de relaes
da aplicao estabelecidas entre as transaces so respeitadas. Para tal, aplicam-se as seguintes regras
sempre que se comprime um par de transaces a e b usando qualquer das regras especicadas:
Se a pertence a um conjunto de transaces alternativas A (relao alternativas), todas as transac-
es A \{a} so removidas da sequncia produzida. A mesma regra aplicada a b.
Se a pertence a um grupo indivisvel, a transaco que resulta da compresso tambm deve per-
tencer a esse grupo indivisvel (se o resultado for a sequncia vazia, todas as transaces do grupo
indivisvel devem ser executadas com sucesso). A mesma regra aplicada a b.
Se existe uma relao predecessor/sucessor fraco ou predecessor/sucessor entre a e b, essa relao
desaparece.
Se a tem um predecessor (sucessor) t (relao predecessor/sucessor fraco ou predeces-
sor/sucessor), a mesma relao deve ser estabelecida entre a transaco resultado da compresso e
t. A mesma regra aplicada a b.
A sequncia de transaces a propagar para o servidor, armazenada num cliente, comprimida in-
crementalmente. Assim, o cliente verica imediatamente se pode comprimir cada nova transaco
5
10.5 Extraco automtica de relaes
A extraco automtica de relaes entre as transaces mveis executada a partir da anlise esttica
dos seus programas. Este processo consiste em dois passos. Primeiro, para cada transaco, extrai-
-se a informao sobre os dados lidos, os dados escritos, e as pr-condies que levam ao sucesso da
transaco. Segundo, as relaes entre duas transaces so inferidas comparando a informao obtida
anteriormente. Nesta seco detalha-se cada um destes processos.
A anlise esttica de programas [49] foi usada em vrios sistemas com vrias nalidades, entre as
quais se destacam a vericao da correco [48, 69, 10] e equivalncia de programas [92]. No entanto,
que o autor saiba, este trabalho o primeiro a utilizar uma aproximao similar na reconciliao de dados.
A anlise esttica executada no sistema SqlIceCube apresenta algumas caractersticas pouco comuns:
executada durante o funcionamento do sistema e a informao extrada dos programas usada para
inferir relaes diferentes da equivalncia entre dois programas.
5
No mbito do sistema Mobisnap, apenas as transaces no garantidas localmente so comprimidas.
10.5. EXTRACO AUTOMTICA DE RELAES 161
10.5.1 Extraco de informao
A extraco de informao associada a uma transaco mvel executada a partir do seu programa,
analisando estaticamente os vrios caminhos de execuo possveis. Para cada caminho de execuo que
termina numa instruo commit, extrai-se a seguinte informao:
Conjunto de escrita semntico Constitudo pela descrio semntica de todas as modicaes produ-
zidas pela transaco.
Conjunto de leitura semntico Constitudo pela descrio semntica de todos os elementos de dados
lidos e usados pela transaco (os elementos de dados lidos e no usados so ignorados).
Conjunto de pr-condies Constitudo por todas as condies usadas para determinar o caminho de
execuo.
Durante o processo de anlise esttica, as seguintes instrues so processadas de forma especial:
Instruo select C into X from T where Cond Atribui ao valor da varivel X o valor especial
read(T,Cond,C) que descreve semanticamente os dados lidos. Este valor no pode ser obtido de
forma esttica porque depende do estado da base de dados no momento em que a transaco mvel
executada.
Instruo update T set C = Val where Cond Adiciona ao conjunto de escrita a seguinte descrio se-
mntica associada instruo de actualizao: update(T,Cond,C,Val).
Instruo insert into T[Cols] values Vals Adiciona ao conjunto de escrita a seguinte descrio semn-
tica associada instruo de insero: insert(T,Cols,Vals).
Instruo delete from T where Cond Adiciona ao conjunto de escrita a seguinte descrio semntica
associada instruo de remoo: delete(T,Cond).
Instruo if(Cond) then ... else ... No caso de o valor de Cond ser conhecido nenhuma aco especial
executada. No caso de o valor de Cond ser desconhecido sero analisados os dois possveis
caminhos de execuo, assumindo num caso que a condio verdadeira e adicionando o valor
precond(Cond) ao conjunto de pr-condies e no outro que a condio falsa e adicionando
precond(not Cond) ao conjunto de pr-condies.
Durante a anlise esttica, qualquer expresso, e, cujo valor dependa de uma varivel com um valor
obtido numa instruo de leitura, temigualmente umvalor especial, expr(e). Este valor pode ser atribudo
a uma varivel (numa instruo de atribuio) ou usado em qualquer das instrues de acesso base de
dados (apresentadas anteriormente).
O conjunto de leitura associado a um caminho de execuo obtido a partir dos elementos dos
conjuntos de escrita e do conjunto de pr-condies, obtendo todos os valores especiais read(. . .) usados
na descrio semntica desses elementos.
Associado a cada caminho de execuo que termina com sucesso obtm-se um grupo de informao
semntica composto pelo conjunto de escrita, de leitura e de pr-condies. Relativamente aos caminhos
de execuo que terminam numa instruo rollback no se obtm qualquer informao. Assim, associada
a cada transaco podem existir vrios grupos de informao semntica.
Exemplo: Considere-se o seguinte programa:
1 BEGIN
2 IF c1 THEN
3 IF c2 THEN
4 COMMIT;
5 ELSE
6 COMMIT;
7 END IF;
8 ELSEIF c3 THEN
9 ROLLBACK;
10 END IF;
11 END
Este programa tem quatro caminhos de execuo possveis. O primeiro termina na instruo commit
da linha 4. Neste caso, o conjunto de pr-condies inclui os valores precond(c1) e precond(c2). O
segundo termina na instruo commit da linha 6 e o respectivo conjunto de pr-condies inclui os
valores precond(c1) e precond(not c2). O terceiro termina na instruo rollback da linha 9. Assim, no
se extrai informao semntica deste caminho de execuo. O quarto caminho de execuo termina no
m do programa e o conjunto de pr-condies inclui os valores precond(not c1) e precond(not c3).
Desta forma, associado e esta transaco existem trs grupos de informao semntica. Para que
seja possvel executar a transaco num dado estado da base de dados apenas necessrio que todos os
valores de um dos conjuntos de pr-condies seja verdadeiro nesse estado.
Na gura 10.5 apresenta-se uma transaco mvel que introduz uma nova encomenda (semelhante
transaco apresentada na gura 8.1, mas usando identicadores numricos para identicar os produtos,
vendedores e clientes). Neste caso, apenas existe um caminho de execuo possvel, sendo a informao
semntica extrada apresentada na gura como comentrios (linhas iniciadas por - -).
10.5.2 Inferir relaes
As relaes estticas entre cada par de transaces so inferidas a partir da informao semntica extrada
de cada uma das transaces usando as regras que se apresentam nesta subseco. Diz-se que o valor de
uma relao verdadeiro se a relao se estabelece entre as duas transaces e falso no caso contrrio.
Durante a avaliao das regras denidas necessrio vericar se as descries semnticas obtidas
a partir das transaces referem os mesmos elementos de dados. Esta vericao inclui os elementos
BEIGN
SELECT stock,price INTO l_stock,l_price FROM products WHERE id = 80;
-- l_stock = read(products,id=80,stock)
-- l_price = read(products,id=80,price)
IF l_price <= 50.0 AND l_stock >= 10 THEN
-- precond(read(products,id=80,stock)>=10)
-- precond(read(products,id=80,price)<=50.0)
UPDATE products SET stock = l_stock - 10 WHERE id = 80;
-- update(products,id=80,stock,"read(products,stock,id=80)-10")
-- readset += {read(products,id=80,---)}
INSERT INTO orders VALUES (newid,8785,80,10,l_price,to process);
-- insert(orders,(id,client,product,qty,price,status),(newid,80,10,l_price,processing))
COMMIT;
-- readset = {read(products,id=80,stock),read(products,id=80,price),read(products,id=80,---)}
-- writeset = {update(...),insert(...)}
-- precondset = {precond(read(products,id=80,stock)>=10),precond(read(products,id=80,price)<=50.0)}
ELSE
ROLLBACK;
END IF;
END;
Figura 10.5: Informao extrada de uma transaco mvel nova encomenda. A informao obtida de
cada instruo apresentada na linha seguinte (o bloco de declarao de variveis omitido).
de dados alvo das operaes e os elementos de dados usados na seleco dos registos afectados. Por
exemplo, uma instruo de leitura acede no s s colunas lidas, mas tambm s colunas usadas nas
condies de seleco (expressas no elemento where da instruo de leitura).
No prottipo desenvolvido, estas vericaes so executadas usando o sistema genrico de resoluo
de restries JSolver [74]. Anlises semelhantes so efectuadas no mbito dos sistema de bases de dados
na optimizao de interrogaes [4, 75, 21] e nos sistemas de replicao secundria semntica [35, 142].
Por vezes, impossvel determinar estaticamente se duas descries semnticas referem um mesmo
elemento de dados. Por exemplo, duas instrues de leitura que usem condies sobre diferentes colunas
para seleccionar os registos a ler no podem ser comparadas estaticamente de forma precisa. Nestes
casos, se o resultado desta comparao for importante para inferir o valor da relao, deve usar-se o
valor denido por omisso como o valor da relao estabelecido entre as duas transaces. Uma possvel
soluo para este problema apresentado na seco 10.5.4.1.
Os valores denidos por omisso para cada relao foram escolhidos para garantir que possvel
obter uma soluo ptima com o algoritmo de reconciliao apresentado anteriormente. Para tal, em caso
de dvida, as transaces devem ser agrupadas conjuntamente (relao comutativas falsa) e integradas
no conjunto das transaces candidatas (relao favorece verdadeira).
A correco da soluo produzida pelo algoritmo de reconciliao no posta em causa por assumir
um valor diferente para qualquer das relaes denidas (com excepo da relao compensa). Em par-
ticular, assumir que duas transaces so comutativas apenas pode levar a que essas transaces sejam
agrupadas em diferentes parties podendo (eventualmente) impedir a criao de uma soluo ptima
caso elas no sejam independentes.
De seguida apresentam-se as regras usadas para inferir as relaes estticas. Estas regras assumem
que cada transaco apenas tem associada um grupo de informao semntica. Caso as transaces
tenham associados vrios grupos de informao necessrio aplicar as regras que se seguems diferentes
combinaes. Se para uma relao forem obtidos valores diferentes para diferentes combinaes, o valor
da relao o denido por omisso.
Adicionalmente, as regras apresentadas apenas tm em considerao as restries de unicidade. No
caso de existirem outras restries ou invariantes na base de dados, a leitura/escrita de um elemento
de dados, que esteja relacionado com outros elementos atravs de uma restrio/invariante, deve ser
considerada como se todos esses elementos fossemlidos/escritos. Ainformao relativa a estas restries
deve tambm ser usada na inferncia das relaes torna possvel, impossibilita, favorece, desfavorece.
10.5.2.1 Comutativas
Duas transaces mveis t
1
e t
2
so comutativas a menos que alguma das seguintes regras seja verdadeira:
t
1
l um elemento de dados escrito (inserido, actualizado ou removido) por t
2
ou vice-versa.
t
1
escreve um elemento de dados escrito por t
2
, com excepo de escritas comutativas, ou vice-
versa.
Se for impossvel obter o resultado das regras anteriores, deve assumir-se que t
1
e t
2
no so comu-
tativas.
10.5.2.2 Impossibilita
Uma transaco t
1
impossibilita uma transaco t
2
se alguma das seguinte regras for verdadeira.
t
1
modica (insere, actualiza ou remove) a base de dados de forma a tornar falso um dos elementos
do conjunto de pr-condies
6
de t
2
.
As modicaes conjuntas de t
1
e t2 violam uma restrio de unicidade da base de dados.
1
no impossibilita t
2
.
10.5.2.3 Torna possvel
Uma transaco t
1
torna possvel uma transaco t
2
se a seguinte regra for verdadeira.
6
Note-se que um caminho de execuo apenas executado se todas as condies do conjunto de pr-condies forem
verdadeiras.
t
1
modica (insere, actualiza ou remove) a base de dados de forma a que sejam verdadeiros todos
os elementos do conjunto de pr-condies de t
2
.
Se for impossvel obter o resultado da regra anterior, deve assumir-se que t
1
no torna possvel t
2
.
10.5.2.4 Desfavorece
Uma transaco t
1
desfavorece uma transaco t
2
t
1
modica a base de dados de forma a prejudicar a veracidade de, pelo menos, um dos elementos
do conjunto de pr-condies de t
2
. Por exemplo, seja x uma varivel (coluna de um registo) na
base de dados, x x 1 prejudica a veracidade da pr-condio x 10.
1
desfavorece t
2
.
10.5.2.5 Favorece
Uma transaco t
1
favorece uma transaco t
2
t
1
modica a base de dados de forma a favorecer a veracidade de, pelo menos, um dos elementos
do conjunto de pr-condies de t
2
. Por exemplo, seja x uma varivel (coluna de um registo) na
base de dados, x x +1 favorece a veracidade da pr-condio x 10.
1
favorece t
2
.
10.5.2.6 Absorve
Uma transaco t
1
absorve uma transaco t
2
se todas as seguintes regras so verdadeiras.
Todos os registos inseridos por t
2
so removidos por t
1
.
Todos os registos removidos por t
2
so reinseridos por t
1
ou igualmente removidos por t
1
.
Todos os dados actualizados por t
2
so tambm actualizados (usando valores absolutos) por t
1
.
As modicaes produzidas por t
2
no inuenciam a execuo de t
1
.
Estas regras apenas so vlidas se for possvel executar t
1
aps executar t
2
. Assim, deve ser possvel
executar t
1
em todos os estados da base de dados que resultam de executar t
2
num qualquer estado da
base de dados em que tal seja possvel. Para tal, necessrio que as pr-condies de t
1
sejam to gerais
como as pr-condies de t
2
, quando modicadas pelas operaes de modicao denidas em t
2
.
1
no absorve t
2
.
1 BEGIN
2 SELECT status INTO l_status FROM orders WHERE id = 3;
3 -- l_status = read(orders,id=3,status)
4 IF l_status = to process THEN
5 -- precond(read(orders,id=3,status)=to process)
6 UPDATE orders SET status = cancelled WHERE id = 3;
7 -- update(orders,id=3,status,cancelled)
8 UPDATE products SET stock = stock + 30 WHERE id = 79;
9 -- update(products,id=79),stock,stock+30)
10 COMMIT;
11 ELSE
12 ROLLBACK;
13 END IF;
14 END;
Figura 10.6: Informao extrada da transaco mvel cancela encomenda denida sem indireces (o
bloco de declarao de variveis omitido).
10.5.2.7 Compensa
Uma transaco t
1
compensa uma transaco t
2
se todas as seguintes regras so verdadeiras.
Todos os registos inseridos por t
2
e apenas esses so removidos por t
1
.
Todos os registos removidos por t
2
so reinseridos por t
1
.
Todos as actualizaes executadas por t
2
so compensadas por actualizaes executados por t
1
.
t
1
no produz mais nenhuma modicao.
Como anteriormente, as regras anteriores apenas so vlidas se for possvel executar t
1
aps executar
t
2
. Se for impossvel obter o resultado das regras anteriores, deve assumir-se que t
1
no compensa t
2
.
10.5.3 Exemplos
Para exemplicar o funcionamento do mecanismo de inferncia automtica de relaes vamos considerar
os exemplos apresentados na seco 9.1.
Suporte a uma fora de venda Relativamente ao suporte a uma fora de vendas mvel considerem-se
as transaces de introduo e cancelamento de uma encomenda apresentadas nas guras 10.5 e 10.6
respectivamente. A partir da informao extrada, apresentada nas guras, possvel estabelecer as
seguintes relaes.
Duas operaes, quaisquer que sejam, relativas a diferentes produtos so sempre comutativas. Assim,
possvel dividir o problema da reconciliao emsubproblemas, cada umrelativo a umproduto diferente.
Duas encomendas relativas ao mesmo produto no so comutativas e desfavorecem-se mutuamente
porque a subtraco de uma constante positiva existncia (stock) do produto prejudicial para a vera-
cidade da condio que verica se a existncia disponvel suciente para satisfazer a encomenda.
1 ------ INSERE MARCAO: 16-FEB-2002 s 10:00, vendedor=J.Smith
2 BEGIN
3 id = newid;
4 -- id = 64374
5 SELECT count(*) INTO cnt FROM datebook WHERE day=16-FEB-2002 AND hour>=9 AND hour<12 AND user=J.Smith;
6 -- cnt = read(datebook,day=16-FEB-2002 AND hour>=9 AND hour<12 AND user=J.Smith,count(*))
8 -- precond(read(datebook,...,count(*))=0)
9 INSERT INTO datebook VALUES( id, 16-FEB-2002, 10, J.Smith, Demonstrao BLUE THING);
10 -- insert(datebook,(id,day,hour,user,info),
11 -- (64374,16-FEB-2002,10,J.Smith,Demonstrao BLUE THING))
12 COMMIT 16-FEB-2002; --- Conclui e devolve marcao
13 END IF;
14 ROLLBACK;
15 ON ROLLBACK NOTIFY( SMS, 351927435456, Marcao impossvel... );
16 END;
Figura 10.7: Informao extrada da transaco mvel que introduz uma nova marcao simples numa
agenda partilhada (o bloco de declarao de variveis omitido).
Dois cancelamentos relativos mesma encomenda impossibilitam-se mutuamente porque aps can-
celar uma encomenda (atribuindo-lhe o estado cancelada) no possvel voltar a cancel-la (porque o
seu estado j no a processar). Dois cancelamentos de encomendas diferentes relativas ao mesmo
produto so comutativas porque a operao executada sobre a existncia do produto comutativa.
O cancelamento de uma encomenda favorece a introduo de uma nova encomenda relativa ao
mesmo produto, porque a adio de uma constante positiva existncia (stock) do produto favorvel
veracidade da condio que verica se a existncia disponvel suciente para satisfazer a encomenda.
A introduo de uma encomenda torna possvel o cancelamento da mesma encomenda porque o
registo da encomenda torna verdadeira a pr-condio do cancelamento. No entanto, ao contrrio do que
se poderia esperar, o cancelamento no compensa a introduo da encomenda porque ca registado no
sistema o facto de a encomenda ter existido e ter sido cancelada. Este exemplo mostra a diculdade de
utilizar, na prtica, as operaes de compresso de uma sequncia de operaes.
Adicionalmente, como se explica prxima seco, pode estabelecer-se a relao predecessor/sucessor
fraco entre uma transaco que submete uma encomenda e outra que remove a mesma encomenda no
mesmo caminho de execuo porque a remoo acede ao registo da encomenda inserido anteriormente
pela submisso da transaco.
As relaes extradas automaticamente so as esperadas, levando a que, relativamente a um dado pro-
duto, os cancelamentos sejam efectuados antes da introduo de novas encomendas. Esta aproximao
aumenta a probabilidade de aceitar um maior nmero de novas encomendas.
Agenda partilhada Relativamente a uma agenda partilhada considerem-se as transaces de intro-
duo e remoo de uma marcao, apresentadas nas guras 10.7 e 10.8 respectivamente. A partir da
informao extrada, apresentada nas guras, possvel estabelecer as seguintes relaes.
1 ------ REMOVE MARCAO: 16-FEB-2002 s 10:00, utilizador=J.Smith, id=3476554
2 BEGIN
3 SELECT count(*) INTO cnt FROM datebook
4 WHERE id=3476554 AND day=16-FEB-2002 AND hour=10 AND user=J.Smith;
5 -- cnt = read(datebook,id=3476554 AND day=16-FEB-2002 AND hour=10 AND user=J.Smith,count(*))
6 IF (cnt > 0) THEN
7 -- precond(read(datebook,...,count(*))>0)
8 DELETE FROM datebook WHERE id = 3476554 AND day=16-FEB-2002 AND hour=10 AND user=John Smith;
9 -- delete(datebook,id=3476554 AND day=16-FEB-2002 AND hour=10 AND user=J.Smith)
10 COMMIT;
11 END IF;
12 ROLLBACK;
13 END;
Figura 10.8: Informao extrada da transaco mvel que cancela uma marcao numa agenda parti-
lhada usando os detalhes da marcao (o bloco de declarao de variveis omitido).
Duas operaes relativas a marcaes no sobrepostas so comutativas. A remoo de uma marca-
o favorece a introduo de uma marcao sobreposta com a primeira, porque a remoo do registo da
marcao favorvel inexistncia de um registo que impossibilite a introduo da marcao. A intro-
duo de uma marcao torna possvel a remoo da mesma marcao porque o registo inserido garante
a veracidade da pr-condio de remoo.
As relaes inferidas so as esperadas, levando execuo das operaes de remoo antes das
operaes de introduo de novas marcaes. As operaes relativas mesma marcao so executadas
pela ordem esperada, i.e., as remoes aps as inseres.
Sistema de reserva de bilhetes de comboio As relaes inferidas relativamente s transaces de-
nidas no sistema de reserva de bilhetes de comboio so idnticas s obtidas na aplicao de suporte a
uma fora de vendas. Note-se que o facto de ser necessrio obter o identicador do bilhete vendido
no inuencia as relaes inferidas porque esses elementos de dados no inuenciam as pr-condies
denidas.
10.5.4 Extenses
At ao momento descreveu-se o funcionamento bsico da inferncia de relaes semnticas a partir
do cdigo das transaces mveis. As funcionalidades descritas foram implementadas no prottipo do
sistema SqlIceCube. Nesta subseco propem-se algumas extenses ao modelo bsico descrito. Estas
extenses esto a ser implementadas no sistema SqlIceCube.
Os exemplos apresentados na subseco anterior mostram exemplos em que possvel inferir as
relaes esperadas a partir do cdigo das transaces mveis. No entanto, como se referiu anterior-
mente, existem situaes em que no possvel obter imediatamente a informao semntica necessria
para o processo de inferncia de relaes. Nesta subseco discutem-se essas situaes e apresentam-se
solues automticas para ultrapassar as diculdades surgidas. Os programadores podem tambm con-
tribuir para melhorar o funcionamento do sistema de inferncia automtica evitando escrever transaces
mveis que originem as situaes descritas.
10.5.4.1 Descries semnticas
Um dos problemas que pode surgir durante o processo de inferncia de relaes a diculdade ou
impossibilidade de comparar duas descries semnticas de forma precisa. Este problema pode ser
consequncia da utilizao de valores lidos pela transaco nas condies de seleco de registos das
operaes de leitura e escrita (indireces) ou da utilizao de condies sobre colunas diferentes de
uma mesma tabela (condies incompatveis).
Indireces A transaco mvel de cancelamento de uma encomenda apresentada na gura 9.1 exem-
plica o problema da utilizao de indireces. Nesta transaco, a actualizao da existncia do produto
cancelado (na linha 6) efectuada usando a informao obtida a partir do registo da encomenda (na li-
nha 3). Em particular, impossvel saber qual o produto envolvido no cancelamento e se a operao de
actualizao adiciona um valor positivo ou negativo existncia do produto. Assim, impossvel inferir
de forma exacta as relaes estabelecidas entre esta e qualquer outra transaco mvel de introduo ou
cancelamento de uma encomenda porque no possvel vericar se as transaces acedem aos mesmos
elementos de dados e como que estes so actualizados.
Este problema pode ser ultrapassado combinando a anlise esttica com a avaliao dinmica das
constantes. Dado um conjunto de transaces a reconciliar, existem elementos de dados lidos que no
so modicados por nenhuma transaco (qualquer que seja o caminho de execuo percorrido na tran-
saco). Durante o processo de reconciliao, estes elementos de dados so constantes e o seu valor pode
ser obtido a partir da base de dados e usado no processo de inferncia de relaes.
Esta aproximao permite obter, em muitas situaes, a informao necessria avaliao das regras
de inferncia de relaes. No exemplo anterior, a informao relativa encomenda cancelada (identi-
cador do produto e quantidade envolvida) so constantes. Assim, a transaco a processar, obtido o valor
das constantes, ser semelhante apresentada na gura 10.6, a qual permite inferir as relaes esperadas.
Para vericar se um elemento de dados constante igualmente necessrio comparar as descries
semnticas das escritas. No entanto, como as instrues de escrita incluem geralmente o identicador do
registo modicado, tende a ser possvel efectuar essa vericao.
Condies incompatveis As transaces mveis de introduo e cancelamento de uma marcao apre-
sentadas, respectivamente, nas guras 10.7 e 9.2 exemplicam o problema da utilizao de condies
incompatveis. Quando se cancela uma marcao usa-se o seu identicador, enquanto na vericao da
possibilidade de inserir uma marcao se usam os detalhes das marcaes (para vericar que no existe
nenhuma marcao sobreposta). Assim, impossvel vericar imediatamente se as operaes de leitura
e escrita acedem aos mesmos elementos de dados
7
.
Como a informao relativa a uma marcao , em geral, constante, possvel estender a aproxima-
o anterior para ultrapassar este problema. Assim, possvel obter informao adicional relativa aos
registos acedidos nas operaes de leitura e escrita. Esta informao pode ser suciente para efectuar
uma comparao precisa entre as condies expressas em diferentes operaes de leitura e escrita.
Na operao de cancelamento apresentada anteriormente, seria possvel obter a informao relativa
marcao a cancelar. Assim, aps obter a informao adicional, a transaco a processar seria equivalente
apresentada na gura 10.8, a qual permite inferir as relaes esperadas entre as transaces.
10.5.4.2 Ciclos
Uma transaco mvel que inclua ciclos (por exemplo, instrues for) pode ser processada da seguinte
forma (durante a fase de extraco de informao).
Quando possvel determinar o valor da varivel de controlo do ciclo, o processamento tri-
vial. Neste caso, basta analisar repetidamente as instrues do bloco do ciclo enquanto o valor
da varivel de controlo satiszer a condio de repetio. Por exemplo, num ciclo for i in 1..3
loop, deve repetir-se a anlise das instrues internas ao ciclo trs vezes, com a varivel i a tomar
consecutivamente os valores 1, 2 e 3.
Quando o valor da varivel de controlo depende de um valor lido da base de dados (por exemplo,
o ciclo controlado por um cursor) existem duas situaes. Se possvel determinar que esses
valores so constantes, possvel analisar o ciclo como anteriormente aps resolver a indireco.
Caso contrrio, a informao obtida incluir sempre indireces. O estudo deste problema, recor-
rente na anlise esttica de programas [49], bem como o benefcio que se pode extrair da obteno
da informao adicional, um tpico de trabalho futuro.
7
Neste caso, apenas impossvel determinar de forma precisa se duas transaces so comutativas. Todas as outras relaes
podem ser inferidas correctamente apesar da informao obtida no ser ptima. Uma nova marcao torna possvel o cance-
lamento da marcao respectiva, porque o registo inserido garante a veracidade da pr-condio do cancelamento. Qualquer
outra nova marcao no favorece nem desfavorece um cancelamento porque possvel vericar que as modicaes no tm
inuncia na pr-condio do cancelamento (usando o identicador da marcao). Por omisso, qualquer cancelamento favo-
rece uma nova marcao (como esperado). Um cancelamento no desfavorece uma nova marcao porque a remoo de um
registo nunca modica a base de dados de forma desfavorvel para a pr-condio da insero de uma nova marcao.

init stats
IF c1 THEN
alt. stats 1
COMMIT
ENDIF
IF c2 THEN
alt. stats 2
COMMIT
ENDIF
....
IF cn THEN
alt. stats n
COMMIT
ENDIF
ROLLBACK
conjunto ordenado de
alternativas
init stats
IF c2 AND NOT c1 THEN
alt. stats 2
COMMIT
ELSE
ABORT
ENDIF
init stats
IF c1 THEN
alt. stats 1
COMMIT
ELSE
ABORT
ENDIF
...
init stats
IF cn AND NOT c1 AND
... THEN
alt. stats n
COMMIT
ELSE
ABORT
ENDIF
Figura 10.9: Diviso de uma transaco composta por uma sequncia de instrues if num conjunto
ordenado de transaces alternativas.
10.5.4.3 Transaces complexas
Omecanismo de inferncia de relaes pode ter diculdade emlidar comtransaces longas e complexas
que acedam a muitos elementos de dados ou incluam vrios caminhos de execuo possveis. Devido
a estas caractersticas, estas transaces podem estabelecer relaes, possivelmente contraditrias, com
um elevado nmero de outras transaces. Assim, as relaes estabelecidas podem tornar-se inteis para
guiar a pesquisa executada pelo algoritmo de reconciliao.
Por exemplo, a utilidade da relao de comutatividade consiste em separar as transaces em con-
juntos de transaces independentes. O facto de as transaces complexas tenderem a ser comutativas
com um menor nmero de outras transaces pe em causa a possibilidade de separar as transaces a
reconciliar e, portanto, o papel que esta relao deve desempenhar.
Para evitar estes problemas, a API do sistema SqlIceCube permite aos programadores submeterem
as transaces longas como um conjunto de pequenas transaces ligadas pelas relaes da aplicao
apropriadas. No prottipo do sistema Mobisnap, esta API no est directamente disponvel
8
.
O sistema SqlIceCube pode ainda pr-processar as transaces mveis complexas e dividi-las num
conjunto de pequenas transaces ligadas pelas relaes da aplicao apropriadas. As seguintes regras
de pr-processamento podem ser aplicadas:
A separao dos vrios caminhos de execuo de uma transaco mvel num conjunto ordenado
de transaces alternativas (usando as relaes alternativas e predecessor/sucessor fraco). Nas
8
Para permitir que as aplicaes especiquem as relaes da aplicao directamente, garantindo o respeito pelas relaes
denidas durante o processamento normal, poder-se-ia usar a seguinte aproximao. As transaces ligadas pela relao grupo
indivisvel so executadas como uma nica transaco apenas aps a submisso da ltima transaco que pertena ao grupo
indivisvel. Para respeitar as outras relaes apenas necessrio abortar as transaces cuja execuo viole as relaes estabe-
lecidas, tendo em conta as transaces j executadas com sucesso.

init stats
IF c1 THEN
IF c2 THEN
alt. stats 1
COMMIT
ELSE
alt. stats 2
COMMIT
ENDIF
ELSEIF c3 THEN
alt. stats 3
COMMIT
ELSE
ROLLBACK
ENDIF

conjunto ordenado de
alternativas
init stats
IF c3 AND NOT c1
THEN
alt. stats 3
COMMIT
ELSE
ABORT
ENDIF
init stats
IF c1 AND NOT c2
THEN
alt. stats 2
COMMIT
ELSE
ABORT
ENDIF
init stats
IF c1 AND c2 THEN
alt. stats 1
COMMIT
ELSE
ABORT
ENDIF
Figura 10.10: Diviso de uma transaco composta por um conjunto de instrues if encadeadas num
conjunto ordenado de transaces alternativas.
guras 10.9 e 10.10 apresentam-se exemplos deste pr-processamento.
A diviso de uma transaco longa num conjunto de pequenas transaces associadas num grupo
indivisvel e ligadas, se necessrio, pela relao predecessor/sucessor.
O sistema pode ainda inferir automaticamente a causalidade entre as transaces submetidas por
uma aplicao usando a seguinte regra: se uma transaco aceder (ler ou modicar) a um elemento
de dados escrito por uma transaco submetida anteriormente, pode assumir-se que existe uma relao
predecessor/sucessor fraco (a segunda transaco deve ser executada aps a execuo da primeira).
10.6 Observaes nais
O sistema SqlIceCube um sistema de reconciliao genrico que aborda o processo de reconciliao
como um problema de optimizao, aproximao da qual foi pioneiro o sistema IceCube [85]. O sistema
pesquisa o espao de possveis solues ecientemente [133, 134] com base numa heurstica baseada na
informao semntica associada s transaces mveis.
Ao contrrio dos sistemas de reconciliao que exigem que o programador exponha a semntica
das operaes, o sistema SqlIceCube o primeiro a incluir um mecanismo de inferncia automtica
que permite extrair a informao semntica necessria a partir do cdigo das transaces mveis. Esta
aproximao permite simplicar bastante a utilizao dumsistema de reconciliao baseado na utilizao
da informao semntica. Uma aplicao pode, caso o deseje, impor relaes arbitrrias adicionais entre
as transaces que executa.
Os exemplos apresentados mostram que, caso se tenham alguns cuidados na denio das transac-
es mveis, o sistema SqlIceCube consegue inferir as relaes semnticas esperadas. As extenses
propostas permitem eliminar (a maioria) esses cuidados.
Captulo 11
Trabalho relacionado
Agesto de dados emsistemas distribudos de larga escala temsido umtpico de investigao importante
e inclui um grande conjunto de problemas. Em particular, nos ltimos anos tem sido dedicada grande
ateno ao desenvolvimento de solues que permitam lidar com as caractersticas intrnsecas dos sis-
temas de computao mvel [7, 149]. Algumas das solues propostas so apresentadas conjuntamente
em vrios artigos e livros recentes [124, 78, 147, 13].
Neste captulo, discutem-se os problemas de gesto de dados abordados nesta dissertao e apresen-
tam-se as solues mais relevantes propostas anteriormente, com particular destaque para os problemas
relacionados com a replicao dos dados. Alguns dos problemas descritos neste captulo no foram in-
vestigados no mbito desta dissertao. A sua descrio permite, no entanto, ter uma perspectiva mais
abrangente dos problemas e abordagens propostas para a gesto de dados partilhados em ambientes de
computao mvel.
11.1 Replicao
A replicao uma tcnica fundamental na criao de servios distribudos, na qual vrias elementos
de um sistema distribudo mantm cpias de um objecto. As suas potenciais vantagens so o aumento
da disponibilidade e a melhoria do desempenho. Nesta seco discutem-se vrios aspectos relacionados
com a replicao.
11.1.1 Modelos
11.1.1.1 Replicao pessimista
Os algoritmos de replicao pessimista oferecem uma semntica de cpia nica (single-copy serializabi-
lity), fornecendo a iluso que existe uma nica cpia de cada objecto que evolui sequencialmente. Assim,
as operaes de leitura e escrita apenas podem ser executadas se for possvel aceder ao valor actual do
173
174 CAPTULO 11. TRABALHO RELACIONADO
objecto (caso contrrio so bloqueadas), devendo por isso a execuo das operaes ser sincronizada
entre si (por esta razo, tambm se chama a este tipo de replicao, replicao sncrona ou eager repli-
cation). Vrias formas de alcanar este objectivo foram propostas [17], nas quais se podem distinguir
dois elementos fundamentais. Primeiro, o nmero de rplicas que acedido em cada operao, que pode
variar entre uma estratgia simples de l-uma-rplica-escreve-todas [114] at aproximaes que lem e
escrevem quorum de rplicas [163]. Segundo, a estratgia usada para sincronizar e ordenar a execuo
das vrias operaes (de escrita), entre as quais se podem referir a utilizao de uma rplica princi-
pal [8, 95], de um sistema de comunicao em grupo sncrono [83, 2] ou de protocolos de desistncia
progressiva (backoff ) [28].
Embora funcionem bem num ambiente de rede local, as tcnicas de replicao pessimista no so
apropriadas para ambientes de larga escala. Em primeiro lugar, a latncia mais elevada e a menor abi-
lidade das redes de comunicao de larga escala levam a que o tempo de execuo das operaes seja
elevado e, em alguns casos, a uma reduzida disponibilidade (para escrita) dos dados [30] (a utilizao
de sistemas de quorum minimiza este problema). Em segundo lugar, estas tcnicas impedem qualquer
acesso aos dados em situaes de desconexo (ou, em alternativa, a desconexo de uma rplica impede
a modicao dos dados por todos os outros utilizadores).
11.1.1.2 Replicao optimista
Os algoritmos de replicao optimista permitem aos utilizadores aceder a qualquer rplica dos dados, no
pressuposto optimista que os conitos so raros ou possveis de resolver. Assim, as operaes de leitura e
escrita so executadas numa (qualquer) rplica sobre o valor dessa rplica. As operaes de modicao
so propagadas de forma diferida para as outras rplicas (por esta razo tambm se chama a este tipo de
replicao, replicao retardada lazy replication).
A replicao optimista apresenta vrias vantagens relativamente replicao pessimista, das quais
se destacam: o aumento da disponibilidade, permitindo o acesso aos dados desde que uma rplica esteja
acessvel; a exibilidade no uso da rede de comunicaes, permitindo efectuar as comunicaes nos
perodos mais apropriados (em termos de intensidade de trfego, custo e condies de conectividade) e
recorrendo a computadores intermdios; a diminuio do tempo de resposta, permitindo obter o resultado
localmente. Estas vantagens so obtidas sacricando a consistncia dos dados entre as vrias rplicas,
pelo que nem todas as aplicaes podem utilizar este tipo de replicao. No entanto, para permitir a
operao desconectada necessrio recorrer a este tipo de soluo. Esta aproximao usada, no s
nos sistema apresentados nesta dissertao, mas tambm na generalidade dos sistema de gesto de dados
para ambientes de computao mvel [124, 78, 147, 13]. De seguida, discutem-se vrias caractersticas
dos sistemas baseados em replicao optimista.
11.1. REPLICAO 175
11.1.2 Arquitecturas e tipos de rplicas
Um sistema baseado em replicao optimista pode ser construdo usando diferentes arquitecturas. De
uma forma muito simplicada podem identicar-se dois tipos bsicos de arquitectura: cliente/servidor
e participante-a-participante (peer-to-peer). Enquanto numa arquitectura cliente/servidor, o sistema
composto por dois tipos de elementos com funes distintas (os servidores e os clientes)
1
, numa arqui-
tectura participante-a-participante todos os elementos so idnticos e exercem as mesmas funes.
Num sistema cliente/servidor, os clientes podem ser simples (thin clients [78]) ou estendidos (exten-
ded client ou full client [78]). Um cliente simples no mantm nenhuma rplica dos objectos, neces-
sitando de contactar um servidor para executar qualquer operao. Desta forma, este tipo de sistemas
no permite a operao desconectada a menos que um servidor execute na mesma mquina do cliente.
Neste caso, estes sistemas tm propriedades semelhantes s dos sistemas participante-a-participante. O
sistema Bayou [161] usa esta aproximao para suportar a operao desconectada.
Um cliente estendido mantm uma rplica (parcial) dos dados e executa localmente (um subcon-
junto) das funcionalidades do servidor. As operaes submetidas pelas aplicaes podem ser executadas
localmente recorrendo rplica local dos dados. Desta forma, pode suportar-se a execuo de operaes
durante os perodos de desconexo. Os clientes do sistema de cheiros Coda [87] usam esta aproxima-
o.
Num sistema participante-a-participante todas as mquinas mantm rplicas dos objectos. A opera-
o desconectada sobre objectos replicados localmente permitida. O sistema de cheiros Ficus [66] usa
esta aproximao, com cada mquina a manter uma cpia de todos os objectos. O sistema Roam [140]
usa esta aproximao, mas cada mquina mantm apenas um subconjunto dos objectos. O sistema Roam
usa ainda uma organizao hierrquica para simplicar a gesto da replicao entre um nmero muito
elevado de rplicas: as rplicas agrupam-se em conjuntos disjuntos (wards). Em cada ward existe um
rplica eleita, responsvel por comunicar com os outros wards.
Num sistema cliente estendido/servidor, podem identicar-se dois tipos de rplicas [87]. As rplicas
de primeira classe nos servidores e as rplicas de segunda classe (ou cpias da cache) nos clientes.
Em geral, as rplicas de primeira classe so mais completas, disponveis e seguras o algoritmo de
replicao tem como misso principal actualizar estas rplicas. As rplicas de segunda classe so uma
cpia das rplicas de primeira classe, a partir das quais devem ser actualizadas regularmente.
O nmero de rplicas principais nos sistemas cliente/servidor e o nmero de rplicas nos sistema par-
ticipante-a-participante geralmente varivel. Em geral, a criao deste tipo de rplica uma operao
que deve ser efectuada pelo administrador do sistema [101, 87]. No entanto, existem sistemas [172, 86]
que criam novas rplicas automaticamente para manter uma boa qualidade de servio.
1
Uma mesma mquina pode conter um elemento servidor e um elemento cliente.
Os sistemas apresentados nesta dissertao so baseados na arquitectura cliente estendido/servidor.
Esta aproximao permite suportar um elevado nmero de clientes capazes de modicar os objectos,
cada um mantendo rplicas de apenas um subconjunto de objectos. No entanto, o algoritmo de replicao
principal, responsvel por controlar a evoluo dos objectos, executado apenas entre os servidores. O
reduzido nmero de servidores e a sua boa conectividade permite que as operaes sejam reectidas em
todas as rplicas principais rapidamente. Aexistncia de mltiplos servidores (DOORS) permite fornecer
uma maior disponibilidade das rplicas principais custa do aumento de complexidade na reconciliao.
A criao de uma nova rplica num servidor (DOORS) deve ser efectuada pelo administrador do sistema.
A possibilidade de os clientes comunicarem entre si para actualizar as suas cpias dos objectos permite
que quaisquer dois elementos do sistema cooperem sem necessidade de contactar um servidor, ultrapas-
sando uma das limitaes geralmente apontadas aos sistemas cliente/servidor [139]. Relativamente a
um sistema participante-a-participante, esta aproximao tem a desvantagem de a sincronizao entre
os clientes ser, em geral, mais primitiva. No entanto, o menor nmero de rplicas principais existentes
simplica a gesto da consistncia das rplicas.
11.1.3 Unidade de replicao
A unidade de replicao o menor elemento que pode ser replicado independentemente, a que se chama
genericamente objecto. A utilizao de unidades de replicao de grandes dimenses tem vantagens,
de entre as quais se destacam as seguintes: simplica a gesto da replicao, devido ao menor nmero
de objectos existentes; e diminui a probabilidade da ocorrncia de erros devido no replicao de
algum objecto. No entanto, a grande dimenso dos objectos impe elevadas exigncias de recursos para
armazenar e obter uma nova rplica de um objecto. Estas exigncias podem estender-se propagao de
modicaes, no caso de ser necessrio propagar o novo estado de todo o objecto.
Assim, enquanto computadores bem conectados com grande capacidade de armazenamento podem
satisfazer as necessidades relativas utilizao de unidades de replicao de grandes dimenses, os
computadores mveis fracamente conectados e com limitada capacidade de armazenamento necessitam
de utilizar unidades de replicao de pequenas dimenses.
Nos sistemas cliente/servidor (Coda [87], Oracle Lite [115], Objectivity [109]), em que se pressupe
a diferena de qualidade entre os clientes e os servidores, comumexistiremduas unidades de replicao.
Por exemplo, no sistema Coda, a unidade de replicao entre os servidores o volume (conjunto de
cheiros), enquanto os clientes podem obter cpias de cheiros individuais. A aproximao utilizada
no sistema DOORS semelhante: os servidores replicam conjuntos de coobjectos, enquanto os clientes
podem obter cpias parciais de coobjectos individuais.
Nos sistema participante-a-participante, em geral, apenas existe uma unidade de replicao. Quando
11.1. REPLICAO 177
a unidade de replicao de grandes dimenses (conjunto de cheiros no sistema Ficus [66] e base de
dados no sistema Bayou [161]), o sistema tem diculdade em suportar computadores com pequena capa-
cidade de armazenamento, como comum nos computadores portteis. Quando a unidade de replicao
menor (um cheiro no sistema Roam [140]), o sistema tem de gerir um elevado nmero de objectos.
Dimenso da menor unidade de replicao A dimenso da menor unidade de replicao deve ser
sucientemente pequena para que no se repliquem dados desnecessrios e sucientemente grande para
que a gesto do processo no se torne demasiado complexa. Como se discutiu na seco 2.3.5, a unidade
de manipulao de um sistema de gesto de dados , por vezes, inadequada como unidade de replicao.
Assim, no sistema DOORS, a unidade de replicao denida pelos programadores de acordo com o
modo como os objectos esto internamente organizados. Esta aproximao permite adequar a unidade
de replicao s caractersticas dos dados manipulados por cada aplicao. Uma aproximao seme-
lhante foi usada nos sistemas Javanaise [68] e Perdis [51] para melhorar o desempenho num ambiente de
computao distribuda.
O agrupamento automtico de objectos, como executado nos sistemas de bases de dados orientadas
para os objectos [165], no soluciona o problema de gesto, porque o sistema continua a ter de lidar
com todos os objectos no momento de determinar quais devem ser replicados. Pelo contrrio, no sistema
DOORS, a unidade de replicao dene uma caixa negra, o que minimiza o nmero de objectos com
que o sistema necessita de lidar. Num sistema de cheiro possvel dividir um documento longo em
vrios cheiros, obtendo um resultado semelhante ao proposto no sistema DOORS. No entanto, esta
aproximao no natural.
Adicionalmente, a unidade de replicao denida no sistema DOORS, o subobjecto, dene um ele-
mento no qual possvel executar operaes de forma independente. Ao contrrio do que acontece nos
sistemas desenvolvidos para ambientes distribudos, nos quais possvel replicar incrementalmente [166]
os objectos necessrios ao funcionamento da aplicao, num ambiente de computao mvel esta propri-
edade importante por permitir o funcionamento (ainda que parcial) durante os perodos de desconexo.
No sistema Mobisnap, a unidade de replicao o subconjunto de um registo. No entanto, a espe-
cicao dos dados a replicar efectuada usando instrues de interrogao, o que permite lidar com
os objectos a nvel semntico. Esta aproximao semelhante adoptada nos sistemas de bases de
dados relacionais que suportam computao mvel [115] e nas solues de replicao secundria se-
mntica [35, 142].
11.1.4 Replicao antecipada
Durante os perodos de desconexo necessrio recorrer a rplicas locais dos objectos. Assim, antes
de se desconectarem, os computadores mveis devem obter uma rplica dos objectos que se prev se-
rem necessrios. Este processo designa-se por replicao antecipada (prefetching ou hoarding) e deve
ser executado por todos os computadores mveis que no repliquem a totalidade dos dados (o que s
acontece em alguns sistemas participante-a-participante).
Uma tcnica simples de replicao antecipada consiste em delegar nos utilizadores a especicao
dos objectos que vo ser necessrios. O sistema limita-se a manter uma cpia actualizada dos objectos
especicados. Esta aproximao usada, por exemplo, no sistema Oracle Lite [115].
Quando os clientes dispem de muito espao para armazenar as rplicas secundrias, a utilizao
de algoritmos de replicao secundria (caching) tradicionais [141, 54], como por exemplo o algoritmo
menos recentemente utilizado (least recently used), pode ser suciente para suportar a operao des-
conectada. Neste caso, o sistema de replicao antecipada limita-se a actualizar o estado das rplicas
locais. No entanto, estes algoritmos simples tm diculdade em suportar a mudana do foco da ac-
tividade do utilizador. Para ultrapassar este problema, pode combinar-se a utilizao dum algoritmo
de replicao secundria com a soluo anterior, em que o cliente mantm cpias de um conjunto de
objectos especicados pelo utilizador. Esta aproximao usada no sistema Coda [87].
Recentemente, foram propostas tcnicas de replicao antecipada baseadas numa anlise mais com-
plexa dos acessos efectuados pelos utilizadores [160, 91, 151].
O estudo de solues de replicao antecipada est fora do mbito do trabalho desta dissertao. Os
sistema desenvolvidos incluem um subsistema de replicao antecipada que informado dos objectos
acedidos pelos utilizadores. Nos prottipos foram implementadas solues simples, baseadas na utili-
zao de um algoritmo de replicao secundria simples combinado com a especicao, por parte dos
utilizadores, dos objectos que devem ser replicados.
11.1.5 Invocao cega
Durante os perodos de desconexo, o acesso aos dados suportado recorrendo a uma cpia local. No
entanto, desde que no se repliquem a totalidade dos objectos sempre possvel que o utilizador pretenda
aceder a um objecto do qual no existe uma cpia local. Nesta situao, os sistemas de gesto de dados
reportam a existncia de um erro (cache miss) e no permitem a execuo de qualquer operao.
Como se discutiu na seco 2.3.6, existem situaes em que possvel adoptar uma aproximao
optimista, permitindo aos utilizadores submeter operaes de modicao sobre dados que no replicam.
As solues apresentadas nesta dissertao adoptam esta aproximao, que se chama genericamente de
invocao cega.
11.1. REPLICAO 179
O mecanismo de invocao diferida de procedimentos remotos (QRPC) do sistema Rover [79] o
que mais se aproxima da soluo adoptada nesta dissertao. No sistema Rover, os objectos podem ser
divididos em duas partes que correm no cliente e no servidor e cooperam entre si. O mecanismo de
QRPCs permite invocar um procedimento remoto de forma assncrona. Pode ser usado para obter uma
cpia de um objecto ou para propagar uma operao executada na cpia local do objecto aps esta ter
sido importada do servidor.
O mecanismo de invocao cega proposto nesta dissertao mais geral porque permite invocar
operaes sobre objectos dos quais apenas se possu uma referncia (DOORS) ou no se possui referncia
nenhuma (Mobisnap). O mecanismo de criao de cpias de substituio do sistema DOORS permite,
adicionalmente, observar o resultado provisrio das operaes submetidas.
11.1.6 Propagao das modicaes: propagar o qu?
Para sincronizar as rplicas de um objecto, necessrio propagar entre os elementos do sistema as modi-
caes executadas. Para tal, existem duas tcnicas fundamentais. Primeiro, a propagao do estado, na
qual um elemento do sistema envia uma cpia do estado do objecto para outro elemento. Os seguintes
sistemas utilizam esta tcnica: Coda [87], Oracle Lite [115], Lotus Notes [101], Palm HotSync [117]
e outro protocolos de sincronizao para PDAs [1]. Segundo, a propagao de operaes, na qual um
elemento do sistema envia as operaes que produziram as alteraes no estado do objecto. Os seguintes
sistemas utilizam esta aproximao: Bayou [161], Rover [79] e IceCube [85].
Para avaliar a ecincia de cada uma das tcnicas existem vrios aspectos que podem ser considera-
dos, como se discutiu na seco 2.3.3.
Primeiro, o trfego gerado ao propagar as modicaes. Neste caso, a ecincia depende da situao
e est directamente relacionada com a dimenso dos objectos e da representao das operaes.
Em geral, um objecto tem uma dimenso muito superior de uma operao. No entanto, um objecto
pode reectir um qualquer nmero de operaes. Assim, quando o nmero de operaes executadas pe-
queno, a propagao de operaes tende a ser mais eciente. Para compensar este facto, alguns sistemas
baseados em propagao do estado usam objectos de pequena dimenso (registos no Lotus Notes [101]
e Palm HotSync [117]) ou usam a propagao de operaes em algumas situaes [152]. Alternativa-
mente, quando um elemento tem acesso verso do elemento a quem deseja enviar as modicaes,
pode propagar-se apenas a diferena entre ambas as verses [164].
Quando o nmero de operaes executadas grande, a vantagem da propagao de operaes tende
a reduzir-se (ou anular-se). Para compensar este facto, alguns sistemas baseados na propagao de
operaes comprimem a sequncia de operaes a propagar (por exemplo o sistema Rover [79]).
Segundo, necessrio avaliar a complexidade do processo de obteno e propagao da informao.
Na propagao de operaes necessrio interceptar e armazenar conjuntamente com os dados as ope-
raes executadas. Na propagao do estado apenas necessrio manter a rplica do objecto. Assim, a
propagao de operaes mais complexa.
Terceiro, deve ter-se em considerao a informao disponvel para o processo de reconciliao. A
propagao de operaes permite que o mecanismo de reconciliao utilize a informao semntica asso-
ciada s operaes executadas. Em ambos os casos possvel utilizar a informao semntica associada
ao tipo de dados. Assim, a propagao de operaes permite solues potencialmente mais ecazes,
embora dependa do mecanismo de reconciliao explorar ou no a informao adicional disponvel.
Nos sistemas apresentados nesta dissertao utilizaram-se as duas aproximao. A propagao de
operaes (com compresso) usada para transmitir para os servidores as modicaes executadas pelos
utilizadores, que se assume serem em pequeno nmero. Assim, maximiza-se a informao disponvel
para os mecanismos de reconciliao. A propagao do estado (utilizando objectos tendencialmente de
pequenas dimenses) usada para actualizar as rplicas dos objectos nos clientes. Neste caso, como o
nmero de operaes a enviar se assume ser grande razovel usar esta tcnica. No sistema DOORS
possvel utilizar tambm a propagao de operaes para actualizar as cpias dos clientes no caso
de o nmero de operaes a enviar ser reduzido. No sistema Mobisnap exclui-se esta hiptese por ser
muito complexo manter a sequncia das operaes executadas (que incluem as operaes executadas
directamente por clientes legados).
11.1.7 Deteco das modicaes
Para sincronizar duas rplicas necessrio compar-las para determinar se e como foram modicadas.
Uma aproximao possvel consiste em comparar os seus valores. Como esta operao deve ser
eciente, a comparao integral das rplicas inaceitvel. Assim, necessrio denir um modo de
identicar univocamente o valor de uma rplica. Para tal, pode calcular-se um identicador (quase)
nico a partir do estado do objecto utilizando, por exemplo, uma funo de disperso segura (SHA-1,
MD5)
2
.
Esta soluo permite vericar a igualdade ao nvel do contedo do objecto, mas no permite inferir
qualquer informao sobre a evoluo dos objectos. Assim, as solues usadas nos sistemas de replicao
privilegiam a obteno de informao sobre a evoluo das rplicas (em detrimento da informao exacta
sobre a igualdade dos seus valores, porque se assume que a probabilidade de duas rplicas evoluirem
concorrentemente para o mesmo estado reduzido).
A utilizao de relgios escalares (fsicos ou lgicos [94]) para identicar os valores de uma rplica
(ou operaes) permite denir uma ordem total entre esses valores (ou operaes) que respeita a causali-
2
Esta aproximao usada frequentemente para atribuir identicadores nicos a objectos imutveis [29, 143].
11.1. REPLICAO 181
dade
3
. Esta tcnica permite vericar a desigualdade entre duas rplicas e identicar aquela que pode ser
causalmente dependente da outra.
No entanto, esta tcnica no permite vericar se os valores de duas rplicas foram modicados con-
correntemente. Para tal, uma aproximao possvel consiste em manter duas estampilhas temporais: a
actual e a anterior. Esta aproximao usada, por exemplo, no sistema Palm HotSync [117]. Esta tcnica
apenas exacta quando se usam apenas duas rplicas.
A utilizao de vectores-verso [119] permite vericar de forma exacta se duas rplicas foram mo-
dicadas concorrentemente (quer se use a propagao do estado ou de operaes). Esta tcnica usada
de forma generalizada nos sistemas de replicao com mltiplas rplicas (por exemplo, nos sistemas
Ficus [66], Coda [87], Bayou [161]).
Como a dimenso do vector-verso proporcional ao nmero de rplicas existentes no sistema
4
, os
vectores-verso podem ter dimenses signicativas nos sistema de muito larga-escala. Assim, o pro-
blema da gesto dos vectores-verso, i.e, como se pode introduzir e remover novos elementos de forma
eciente e sem exigir coordenao global, foi estudada em vrios sistemas [5, 140].
No sistema DOORS, cada sequncia de operaes identicada no servidor com um relgio lgico
que permite denir uma ordem total que respeita a causalidade. A cada sequncia de operaes ainda
adicionado, no cliente, um vector-verso que identica o estado do objecto no qual foram produzidas
as modcaes. Como este vector-verso apenas reecte as operaes recebidas nos servidores, apenas
permite traar de forma exacta a dependncia com as operaes j executadas num servidor. Nas aplica-
es desenvolvidas, esta aproximao bsica revelou-se suciente. No entanto, este problema e possveis
solues foram discutidos com maior detalhe na seco 4.1.1.
Quando se pretende reconciliar um conjunto de objectos, podem usar-se as tcnicas anteriores, as-
sociadas ao conjunto de objectos (em vez de associadas a cada um dos objectos) para detectar mo-
dicaes num nvel de granularidade superior. Esta tcnica usada, por exemplo, em sistemas de
cheiros [107, 86] e sistema de bases de dados [137].
11.1.8 Propagao das modicaes: propagar como?
A propagao das modicaes entre as vrias rplicas de um sistema pode ser dividido em dois sub-
problemas: a propagao entre as rplicas principais e a propagao entre as rplicas principais e se-
cundrias. Dizemos que uma rplica principal est presente num servidor e uma rplica secundria est
3
No caso dos relgios fsicos necessrios manter os relgios sincronizados.
4
Note que apenas necessrio manter uma entrada no vector para cada rplica em que so produzidas alteraes. Assim,
se se assumir que em cada momento apenas existe um pequeno nmero de rplicas em que so produzidas alteraes, mas
que a identidade das rplicas varia ao longo do tempo, o problema principal consiste em efectuar a reciclagem automtica
(garbage-collection) das referncias s rplicas que j no so necessrias.
presente num cliente.
Primeiro, abordamos o problema da propagao entre rplicas principais. Nos sistemas de replicao
sncrona [114], as modicaes executadas numa rplica so propagadas imediatamente de forma sn-
crona para todas (ou para um quorum de) as outras rplicas. Esta soluo tem diculdade em lidar com
as falhas e apenas pode ser usada com um nmero reduzido de rplicas. Para que o sistema suporte um
elevado nmero de elementos necessrio que a propagao das modicaes seja efectuada de forma
assncrona (como acontece sempre nos sistema de replicao optimista).
Uma aproximao simples consiste na utilizao dum esquema lazy master, no qual apenas um ser-
vidor recebe as modicaes que propaga assincronamente para as outras rplicas. Outra aproximao
consiste na utilizao de tcnicas de propagao epidmica em que uma rplica propaga todas as modi-
caes conhecidas independentemente da rplica em que tiveram origem. Vrios algoritmos e sistemas
usam esta aproximao [38, 57, 84, 101, 66, 122], nos quais se podem encontrar vrias solues para
a escolha do parceiro e momento da sesso de propagao epidmica (topologias xas anel, rvore,
etc. ou variveis o parceiro escolhido aleatoriamente), para determinar quais as modicaes que
devem ser propagadas e para o protocolo de propagao (unidireccional ou bidireccional). A soluo
ideal para cada sistema depende da topologia da rede de comunicaes e da estratgia de reconciliao
implementada.
No sistema DOORS, a propagao epidmica uni ou bidireccional e usam-se vectores-verso para
determinar de forma exacta quais as operaes que necessitam de ser propagadas. A topologia, momento
das sesses de propagao e coobjectos envolvidos, pode ser denida pelo administrador do sistema de
forma especca para cada volume.
Na propagao das modicaes de uma rplica secundria para uma rplica primria existem, pelo
menos, trs possibilidades. Primeiro, o cliente entrega a modicao a uma s rplica principal. Esta a
aproximao usual (adoptada nos sistemas implementados nesta dissertao). Segundo, o cliente propaga
de forma coordenada a modicao para mais do que uma rplica. Por exemplo, no sistema Coda [87] um
cliente instala uma nova verso de um cheiro em vrios servidores simultaneamente. Esta aproximao
tambm pode ser usada para tolerar falhas bizantinas [28]. Terceiro, um cliente propaga de forma no
coordenada uma modicao para mais do que uma rplica. Neste caso, , em geral, necessrio detectar
a igualdade das modicaes recorrendo a informao criada no cliente. Por exemplo, o sistema lazy
replication [93] mantm identicadores nicos para cada operao.
Quando as rplicas principais so modicadas, os clientes tm de invalidar a cpias locais e obter no-
vas cpias. Para tal, existem duas aproximaes. Primeiro, o cliente verica (periodicamente ou quando
acede aos dados) se a sua cpia permanece actual. Segundo, o servidor informa os clientes das modi-
caes. Esta informao pode conter os novos dados ou apenas informao sobre a sua modicao
11.1. REPLICAO 183
e ser propagado individualmente para cada cliente [107] ou disseminado atravs dum canal (fsico) de
difuso de mensagens [14]. Este problema est fora do mbito do trabalho desta dissertao, tendo-se
implementado a soluo mais simples nos prottipos do sistema DOORS e Mobisnap: o cliente verica
periodicamente a validade das cpias locais.
11.1.9 Reconciliao
A reconciliao consiste em unicar as modicaes executadas sem coordenao em duas (ou mais)
rplicas de um objecto. Este mecanismo elementar usado num protocolo de reconciliao, o qual deve,
em geral, garantir a convergncia nal das vrias rplicas, i.e., garantir que aps um perodo de tempo
nito aps a ltima modicao executada, as vrias rplicas so iguais. De seguida abordam-se as tc-
nicas de reconciliao elementares baseadas na utilizao do estado das vrias rplicas e na propagao
das operaes efectuadas.
11.1.9.1 Utilizao do estado das rplicas
Nesta subseco abordam-se as tcnicas de reconciliao baseadas na utilizao do estado das vrias
rplicas. Estas tcnicas de reconciliao determinam, em cada rplica, qual o novo estado da rplica que
resulta da unicao do estado de duas rplicas.
O primeiro tipo de aproximao consiste em, dado um conjunto de rplicas divergentes, seleccionar
uma rplica como resultado da reconciliao. Usando a regra de escrita de Thomas [163], cada rplica
tem associada uma estampilha temporal (sobre as quais se dene uma ordem total) atribuda aquando da
sua mais recente modicao. O resultado da reconciliao consiste em seleccionar a rplica com maior
estampilha temporal. Vrios sistemas [80, 155] usam esta aproximao. Uma estratgia alternativa
consiste em permitir ao utilizador seleccionar qual o valor que deve ser mantido. Por exemplo, na
sincronizao de PDAs [117] usual poder seleccionar-se qual o valor a manter: o valor do computador
xo ou o valor do dispositivo porttil. A vericao da validade das transaces usando os conjuntos de
leitura e escrita [60] pode ser considerada uma extenso desta aproximao, em que se usam objectos
de reduzidas dimenses, se seleccionam as modicaes mais antigas e se detectam adicionalmente
conitos leitura/escrita.
O segundo tipo de aproximao que vamos considerar consiste na criao e manuteno de verses:
duas rplicas de um objecto modicadas concorrentemente do origem a duas verses, mantidas em
cada uma das rplicas. Os utilizadores podem, posteriormente, unicar essas verses. Deve notar-se
que, neste caso, a existncia de vrias verses de um objecto no considerado um erro, decorrendo do
modo de funcionamento normal do sistema. O sistema Lotus Notes [101] um exemplo tpico do uso
desta aproximao.
O terceiro tipo de aproximao consiste em permitir a denio de funes que unicam as modi-
caes concorrentes com base no estado dos objectos. Essas funes podem usar apenas o estado actual
do objecto nas rplicas a sincronizar [87, 66, 115] ou podem usar verses anteriores [24]. A utilizao de
verses anteriores permite (tentar) inferir as modicaes executadas em cada uma das rplicas (e usar
essa informao no processo de reconciliao), mas requer a manuteno da histria das modicaes.
A remoo de um objecto tratada de forma especial nestas aproximaes. Assim, para cada objecto
removido, mantm-se informao sobre a remoo (death certicate [38])
5
.
11.1.9.2 Utilizao das operaes executadas
Nesta subseco abordam-se as tcnicas de reconciliao baseadas na utilizao das operaes executa-
das. Estas tcnicas de reconciliao determinam, em cada rplica, o modo como se executam as opera-
es recebidas directamente dos utilizadores e das outras rplicas.
Neste tipo de solues, a aproximao base consiste em executar todas as operaes por uma deter-
minada ordem nas vrias rplicas (por exemplo, ordem total, ordem causal ou sem ordem). Para tal, cada
operao , geralmente, identicada por um relgio escalar ou por um vector-verso. Na sua verso mais
simples, o algoritmo de reconciliao executa em cada rplica e determina quais as operaes que, em
cada momento, podem ser executadas respeitando a ordem denida.
Na seco 4.1 j se discutiramas tcnicas de implementao dos diferentes tipos de ordenao usando
informao sintctica (relgios escalares ou vectores-verso) e as suas propriedades. Relativamente or-
dem total, existem vrias aproximaes possveis: utilizar uma rplica primria responsvel por ordenar
as operaes [161, 143]; usar o relgio associado a cada operao para ordenar a operao e informa-
o sobre o estado das outras rplicas para garantir a estabilidade da ordem [57]; utilizar protocolos de
eleio para determinar, em passos sucessivos, quais as operaes a executar em cada momento [82].
Relativamente s outras ordens, cada rplica pode decidir independentemente quais as operaes que
pode executar usando apenas a informao associada a cada operao.
A execuo simples de todas as operaes por uma determinada ordem tem vrias limitaes.
Primeiro, podem existir situaes em que ainda no possvel determinar a ordem nal de uma
operao. Neste caso, pode adoptar-se uma aproximao pessimista em que a operao no executada
enquanto no for possvel determinar a sua ordem. Assim, o estado do objecto pode no reectir todas
as operaes conhecidas.
Uma segunda alternativa consiste em adoptar uma aproximao optimista e executar a operao.
Neste caso, o estado do objecto provisrio porque a ordem de execuo pode ser incorrecta. Se a
5
Note-se que remover apenas o objecto na rplica a leva a ambiguidade aquando da sincronizao com uma rplica b, sendo
impossvel determinar se o objecto foi criado em b ou removido em a.
11.1. REPLICAO 185
ordem de execuo for incorrecta necessrio corrigir o problema. Uma soluo genrica para este
problema consiste em desfazer as operaes executadas fora de ordem e execut-las novamente na or-
dem correcta. Esta tcnica conhecida por desfazer-refazer (undo-redo) [17, 81]. Alternativamente,
possvel transformar a operao a executar de forma a que o resultado da execuo seja equivalente ao
da ordem denida. Esta tcnica conhecida por transformao de operaes [46, 159]. Quando duas
operaes so comutativas, o resultado independentemente da ordem de execuo. Esta informao
pode ser usada para optimizar o algoritmo de ordenao [170, 135].
Para lidar com a existncia de operaes para as quais no se pode garantir a sua ordem, existem
sistemas que mantm duas verses de cada objecto [161]. Uma verso reecte todas as operaes conhe-
cidas e outra reecte apenas as operaes para as quais possvel determinar a ordem nal de execuo.
Esta aproximao usado nos clientes do sistema Mobisnap e pode ser usada no sistema DOORS.
Uma segunda limitao apresentada pela execuo das operaes submetidas concorrentemente por
uma dada ordem que esta aproximao no lida directamente com as consequncias da submisso
concorrente de operaes, i.e., com a existncia de operaes que interferem entre si. Este facto leva
a que o valor do objecto quando a operao executada seja diferente do valor observado aquando da
submisso da operao. Para lidar com este problema foram propostas vrias aproximaes, entre as
quais:
Denir apenas operaes comutativas. Neste caso, as operaes no interferem entre si e podem
ser executadas por qualquer ordem.
Guardar os valores lidos (ou conjunto de leitura) durante a execuo provisria no cliente. Se,
aquando da execuo nal da operao, os valores lidos forem diferentes, deve-se executar uma
funo de resoluo de conitos especicada com a operao [123].
Delegar no cdigo das operaes o tratamento dos problemas relacionados com a execuo con-
corrente das operaes. As solues denidas podem recorrer informao semntica associada
ao tipo de dados e operao executada. Vrios sistemas usam esta aproximao [79, 161]. O
sistema Bayou [161] executa uma soluo particular desta aproximao, na qual uma operao de
escrita composta pela vericao de uma pr-condio (dependency check), por uma modica-
o e por um procedimento que gera uma modicao alternativa quando a pr-condio no
verdadeira aquando da execuo nal da operao (merge procedure).
Usar regras para denir o resultado de duas operaes concorrentes. No sistema Sync [108], os
programadores podem denir o resultado da execuo de duas operaes concorrentes. Este re-
sultado pode ser a execuo das duas operaes pela ordem indicada, de apenas uma operao,
de uma nova operao ou de nenhuma operao. O sistema usa estas regras para tratar as ope-
raes executadas concorrentemente (e denir a sequncia nal de operaes a executar). Uma
caracterstica interessante deste sistema a possibilidade de as regras de resoluo de conitos de
um objecto poderem ser denidas como a composio das regras de resoluo dos objectos que
o compem. Uma aproximao semelhante foi usada para um sistema de cheiros [138]. Neste
caso, um sistema de prova, baseado num conjunto de regras algbricas que denem o resultado
da combinao de duas operaes executadas concorrentemente, usado para produzir uma or-
dem cannica. As operaes com conitos que no podem ser resolvidos no so includas na
sequncia de operaes a executar (os utilizadores podem posteriormente resolver estes conitos
manualmente).
Optimizar a sequncia de operaes que podem ser executadas, ordenando as operaes de acordo
com as suas propriedades/efeitos. Em [123], os autores propem que as transaces executadas
provisoriamente num cliente mvel sejam integradas numa qualquer posio da histria da rplica
principal (implementando uma forma mais fraca de snapshot isolation). O algoritmo mantm uma
sequncia de verses da base de dados e integra uma transaco nesta sequncia (criando uma
nova verso da base de dados) de forma ptima. Para tal, cada transaco inclui uma funo de
resoluo de conitos (que especica o resultado da execuo da transaco numa dada verso da
base de dados) e uma funo de custo (que especica o custo de executar a transaco numa dada
verso da base de dados).
No sistema IceCube [85], a ordenao das operaes vista como umproblema de optimizao, no
qual se procura maximizar as operaes que podemser executadas comsucesso usando informao
semntica associada s operaes. O sistema SqlIceCube, apresentado nesta dissertao, estende
esta aproximao atravs da extraco automtica de informao semntica a partir do cdigo das
transaces (usando tcnicas de anlise esttica de programas [49]).
Transformar as operaes de forma a preservar as intenes dos utilizadores. As operaes sub-
metidas concorrentemente tm de ser executadas sequencialmente, pelo que, quando se executa
uma operao, o estado do objecto pode ser diferente do estado observado aquando da submisso
da operao. A transformao de operaes [46, 159, 118] usada para modicar as operaes de
forma a que o resultado da sua execuo seja o esperado aquando da sua submisso. Esta tcnica
usada geralmente na edio sncrona de documentos e folhas de clculo (e parece especialmente
indicada para lidar com a modicao de parmetros que indicam a posio de um elemento que
pode ser modicada atravs de operaes de insero e remoo). Convm realar que, como se
referiu anteriormente, a transformao de operaes pode ser usada igualmente para permitir a
11.1. REPLICAO 187
execuo das operaes por ordem diferente nas vrias rplicas.
Nenhuma das solues propostas ptima em todas as situaes. Assim, no sistema DOORS, o
framework de componentes permite reutilizar diferentes estratgias de reconciliao. Cada coobjecto
pode seleccionar a soluo mais adequada, i.e., aquela que permite implementar a estratgia de resoluo
de conitos pretendida de forma mais simples.
Independentemente da estratgia de reconciliao escolhida no sistema DOORS ou da integrao do
sistema SqlIceCube no sistema Mobisnap, a execuo nal das operaes no(s) servidor(es) permite que
as operaes lidem de forma especca com os problemas da execuo independente de operaes, por
exemplo, denindo regras de deteco e resoluo de conitos.
11.1.10 Preveno de conitos
A replicao optimista pode levar submisso concorrente de modicaes que actuam sobre os mesmos
objectos. Nas subseces anteriores apresentaram-se tcnicas de reconciliao que permitem unicar
as modicaes executadas concorrentemente. Devido possibilidade de as modicaes produzidas
serem conituantes, apenas possvel determinar o resultado nal de uma operao aps o processo de
reconciliao. Nesta seco abordam-se tcnicas que permitem evitar os conitos e comparam-se estas
tcnicas com as implementadas no sistema Mobisnap.
Os trincos (locks) [60] so a tcnica tradicional para evitar conitos, permitindo que apenas um
utilizador aceda a um objecto em cada momento. No entanto, num ambiente de computao mvel, no
qual os dispositivos mveis podem permanecer desconectados durante longos perodos de tempo, esta
tcnica pode impor restries inaceitveis concorrncia em objectos partilhados por vrios utilizadores:
um dispositivo desconectado impede qualquer acesso a um objecto para o qual possua um trinco.
As verses fracas de trincos (por exemplo, tickle locks [64], trincos optimistas [61], trincos probabi-
lsticos [63]) permitem que se aceda a um objecto sem possuir uma garantia de exclusividade de acesso.
Estas tcnicas optimistas foram propostas para ambientes com boa conectividade, nos quais fornecem
uma razovel probabilidade de acesso exclusivo. No entanto, em situaes de desconexo, as garantias
que podem oferecer so praticamente nulas.
No sistema Prospero [42], estendeu-se a noo de trinco de forma a restringir a divergncia entre
vrios uxos de actividade. Para tal, os utilizadores especicam uma promessa relativa s operaes
que executam e obtm garantias relativas ao estado dos objectos. Estas garantias podem ser usadas para
garantir a inexistncia de conitos. Ao contrrio dos trincos, as promessas e garantias so especicadas
(indirectamente) em termos da execuo de uma dada operao. Por exemplo, a promessa de no modi-
car a estrutura de um documento est associada no execuo da operao de modicao da estrutura
do documento. Assim, o utilizador pode obter a garantia da manuteno da estrutura do documento se
se impedir a execuo da operao de modicao da estrutura.
O modelo de diviso (escrow) [111] permite dividir o valor de uma varivel que represente um re-
curso divisvel (por exemplo, a existncia stock de um qualquer produto) sujeita a uma dada restrio
(por exemplo, o valor da existncia do produto deve ser maior ou igual a zero) por um conjunto de en-
tidades (transaces, rplicas). Cada entidade pode garantir o sucesso das operaes que apenas usam a
parte dos recursos que lhe foram atribudos (garantindo assim que a restrio global permanece vlida).
As operaes executadas sem coordenao podem ser unicadas de forma simples porque apenas podem
ser executadas operaes comutativas (adio e subtraco) sobre as variveis partilhadas. Para manipu-
lar estas variveis, foram introduzidas funes especiais. Este modelo pode ser utilizado para suportar
uma aplicao de suporte a uma fora de vendas num ambiente de computao mvel [90].
O modelo de diviso pode ser generalizado explorando a semntica dos objectos [168]. A ideia con-
siste em dividir objectos grandes e complexos em fragmentos menores que obedecem a certas restries.
Cada fragmento pode ser modicado independentemente, desde que as restries associadas no sejam
violadas. A unicao dos fragmentos pode ser efectuada usando a informao semntica disponvel.
Esta aproximao e a aproximao usada no sistema Prospero [42] apenas podemser usadas de forma
adequada em alguns tipos de dados e so mais apropriadas para sistemas de bases de dados orientadas
para os objectos, nos quais as operaes que podem ser executadas para modicar o tipo de dados so
complexas e esto pr-denidas.
O sistema Mobisnap dene um modelo de preveno de conitos baseado na utilizao de reservas.
Este modelo combina e implementa um conjunto de tcnicas de preveno de conitos (entre as quais a
utilizao de trincos de pequena granularidade e do modelo da diviso). Como se mostrou na seco 8.5,
a combinao de diferentes tcnicas fundamental para a sua utilidade num sistema genrico de bases
de dados relacionais. O sistema Mobisnap verica, de forma transparente, se as reservas disponveis so
sucientes para garantir uma transaco mvel. Esta aproximao permite aos programadores denirem
as transaces da forma habitual (i.e., sem usarem funes especiais para manipular elementos de dados
reservados) e utilizar todas as reservas disponveis (e no apenas aquelas que tenham sido especicadas
no cdigo da transaco).
Alm de evitar os conitos possvel diminuir a probabilidade da sua ocorrncia usando tcnicas de
controlo de divergncia. Vrios mtodos de denir a divergncia entre rplicas foram propostos, assim
como algoritmos para limitar esta divergncia [6, 135, 89]. O sistema TACT [173] permite controlar
a divergncia entre um conjunto de rplicas usando vrias mtricas de divergncia. Esta aproximao
permite s aplicaes denirem a divergncia mxima aceitvel.
Os mecanismos de controlo de divergncia no podem ser usados para garantir o resultado de uma
operao, mas apenas para diminuir a probabilidade da ocorrncia de um conito que impea a sua
11.2. INFORMAO SOBRE A EVOLUO DOS DADOS 189
execuo. Assim, estes mecanismos podem ser considerados como complementares dos mecanismos de
preveno de conitos.
11.2 Informao sobre a evoluo dos dados
A informao sobre a evoluo dos dados e da actividade cooperativa permite a um utilizador conhecer,
no s as modicaes produzidas por outros utilizadores, mas tambm o resultado nal das suas mo-
dicaes. Na generalidade dos sistemas de gesto de dados para ambientes de computao mvel, o
problema da criao e tratamento desta informao ignorado.
A importncia desta informao para o sucesso da actividade cooperativa identicada por vrios
autores [43, 65, 99]. Em geral, as aplicaes cooperativas sncronas providenciam informao sobre a
evoluo dos dados e sobre a actividade cooperativa atravs de pequenos elementos na interface grca
das aplicaes. Por exemplo, nos editores cooperativos sncronos, alm de se apresentar a lista dos utili-
zadores que esto a modicar o documento, usual apresentar as modicaes produzidas por diferentes
utilizadores usando diferentes cores. O sistema de suporte criao de aplicaes cooperativas sncronas
Groupkit [145] inclui um conjunto de pequenos elementos da interface grca que podem ser usados nas
aplicaes para fornecer informao sobre as actividades dos outros utilizadores.
Apesar de se ter identicado a importncia desta informao, a maioria dos sistemas de suporte ao
trabalho cooperativo assncrono (por exemplo, Lotus Notes [80], Prospero [42], Sync [108]) no integram
nenhum mecanismo de suporte manipulao desta informao. Algumas excepes existem.
No sistema CVS [24], um utilizador pode incluir com cada nova verso uma descrio das modi-
caes executadas. Esta informao mantida com cada verso e permite aos utilizadores conhecer as
modicaes produzidas apenas quando acedem aos dados. Uma aproximao semelhante usualmente
adoptada nos sistemas de espao de trabalho partilhado (shared workspace). Por exemplo, o sistema
BSCW [16] permite aos utilizadores observar os eventos executados sobre os documentos do espao par-
tilhado. Estes eventos correspondem s operaes que podem ser executadas sobre um documento (por
exemplo, editar o documento). Assim, estes eventos tm uma elevada granularidade (apenas se especca
que um documento foi modicado e no as modicaes que sofreu) e incluem no s as operaes de
modicao, mas todas as operaes executadas sobre o objecto.
O sistema de edio cooperativa assncrona Quilt [97] permite que um utilizador pea para ser noti-
cado quando so efectuadas modicaes a um documento.
No sistema Placeless Documentos [44], usou-se o mecanismo de propriedades activas (que permite
especicar aces a executar quando um objecto acedido) para fornecer informao sobre a evoluo
dos dados em algumas aplicaes.
Os sistemas apresentados nesta dissertao integram o tratamento desta informao. A informao
sobre a evoluo dos dados criada no cdigo das operaes atravs de funes denidas para o efeito.
O tratamento desta informao integrado no sistema, permitindo manter esta informao com os dados
ou enviar noticaes para os utilizadores usando diferentes transportes.
11.3 Integrao de sesses sncronas
O problemas da integrao de sesses de trabalho sncrono e assncrono tem sido abordado em vrios
sistemas de suporte ao trabalho cooperativo. Vrias aproximaes tm sido propostas.
Uma possvel aproximao consiste em gravar os eventos produzidos numa sesso cooperativa.
Quando um utilizador acede sesso cooperativa num momento posterior, ele pode observar as aces
executadas reproduzindo os eventos armazenados [77, 98].
Greenberg et al. [62] denem um espao de dados partilhado baseado na noo de quarto (room),
onde os utilizadores podem guardar objectos partilhados. As aplicaes executam no mbito de um
quarto, podendo um utilizador ligar-se ao servidor central para observar e modicar o estado do quarto
(utilizando as aplicaes que executam nesse quarto). Os utilizadores que acedem ao mesmo quarto
simultaneamente podem modicar um objecto de forma sncrona. As modicaes assncronas resultam
do acesso a um quarto em diferentes momentos.
O sistema Sepia [67] permite a edio de documentos de hipertexto de forma sncrona e assncrona
usando uma aproximao semelhante.
Qu et al. [136] descrevem um ambiente de educao distncia que combina o trabalho sncrono
e assncrono. Um repositrio WebDav assncrono mantm 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 repositrio assncrono.
As aproximaes anteriores no so apropriadas para ambientes de computao mvel porque reque-
rem o acesso a um servidor central. Adicionalmente, as primeiras solues apenas permitem a existncia
de um nico uxo de actividade (com excepo de perodos de tempo muito curtos durante as sesses
sncronas). Assim, a interaco assncrona restringe-se manipulao da cpia nica de um objecto em
diferentes momentos. No ambiente de educao distncia apresentado [136] possvel existirem ml-
tiplos uxos de actividade. No entanto, os conitos so resolvidos criando mltiplas verses do objecto,
i.e., no possvel integrar automaticamente as modicaes executadas durante estas sesses.
O sistema Prospero [42] permite a manipulao concorrente de cpias de um mesmo objecto. Este
sistema baseado no conceito de stream, no qual se guardam as operaes executadas em cada uxo
de actividade. A implementao de aplicaes sncronas e assncronas possvel usando diferentes
frequncias da sincronizao dos streams. Os streams podem ser usados para integrar sesses sncro-
nas e assncronas fazendo variar a frequncia de sincronizao, mas apenas quando possvel usar as
mesmas operaes e mecanismos de controlo de concorrncia. Uma aproximao semelhante proposta
em [154].
O sistema SAMS [105] permite a edio de documentos estruturados em modo sncrono, assncrono
e multi-sncrono. A diferena entre os vrios modos reside no perodo de tempo que cada elemento do
sistema armazena as operaes executadas antes de as propagar para os outros elementos do sistema.
A integrao, em cada rplica local, das operaes executadas concorrentemente efectuada de forma
idntica em todos os modos atravs da reexecuo das operaes e recorrendo a um mecanismo de
transformao de operaes.
No entanto, como se discutiu na seco 4.4.1, existem aplicaes que necessitam de usar operaes
e mecanismos de reconciliao diferentes durante as sesses sncronas e assncronas. No mbito do
sistema DOORS, props-se uma soluo genrica para a integrao de sesses sncronas e assncronas
com essas propriedades.
Captulo 12
Concluses
A generalizao da utilizao de computadores portteis e de comunicaes sem os criou um novo
ambiente de computao com caractersticas prprias. O sistema de gesto de dados um dos elementos
que se deve adaptar s novas caractersticas para permitir a partilha de dados entre mltiplos utilizadores.
Esta dissertao descreve um conjunto de princpios e tcnicas usados em dois sistema de gesto de
dados para permitir a partilha de informao em ambientes de computao mvel.
Este captulo apresenta um sumrio das principais solues de gesto de dados apresentadas nesta
dissertao e direces de trabalho futuro.
12.1 Sumrio
Nesta dissertao estudou-se a problemtica da gesto de dados partilhados em ambientes de compu-
tao mvel. As solues propostas adoptam como princpio fundamental a explorao da informao
semntica associada aos dados e s aces dos utilizadores.
Nesta dissertao identicou-se, ainda, um conjunto de princpios gerais que, explorando a infor-
mao semntica disponvel, permitem a gesto de dados partilhados por mltiplos utilizadores. Estes
princpios gerais foram desenvolvidos e validados durante o desenho, implementao e teste de dois
sistemas de gesto de dados partilhados para ambientes de computao mvel. Nesta dissertao descre-
vem-se as tcnicas especcas usadas para colocar esses princpios gerais em prtica.
Os sistemas de gesto de dados criados nesta dissertao fornecem uma elevada disponibilidade de
leitura e escrita atravs da combinao das seguintes tcnicas: replicao parcial dos dados nos disposi-
tivos mveis; modelo de replicao optimista; e reconciliao dependente da situao.
Relativamente ao modelo de replicao optimista, os sistemas apresentados nesta dissertao incluem
uma nova caracterstica: a possibilidade de submeter operaes sobre dados no replicados localmente,
designada de invocao cega. Ao contrrio da aproximao habitual, em que se impede qualquer acesso
193
194 CAPTULO 12. CONCLUSES
aos dados no replicados localmente, esta aproximao permite ao utilizador decidir as situaes em que
pode produzir contribuies teis atravs da submisso de operaes de modicao dos dados. Como
estas operaes so sujeitas ao mecanismo de reconciliao do sistema, garante-se a sua integrao no
estado comum dos dados de forma correcta.
Os sistemas de gesto de dados apresentados tambm integram mecanismos de tratamento da infor-
mao sobre a evoluo dos dados. Este problema geralmente negligenciado pelos sistemas de gesto
de dados, apesar desta informao ter sido identicada como importante para o sucesso de uma activi-
dade cooperativa [43, 65, 99]. O mecanismo implementado igualmente importante na noticao do
resultado nal das operaes executadas por cada utilizador, o qual apenas conhecido aps a execuo
nal do mecanismo de reconciliao.
A implementao destas caractersticas comuns em cada um dos sistemas de gesto de dados apre-
sentados exigiu a sua adaptao e possvel extenso de acordo com o modelo de dados usado em cada
um dos sistemas. Por exemplo, a implementao da invocao cega no repositrio de objectos DOORS,
inclui a integrao de um mecanismo de criao de cpias de substituio para que se possa observar o
resultado provisrio das operaes submetidas. Alm destas caractersticas comuns, os sistemas de ges-
to de dados apresentam igualmente um conjunto de caractersticas especcas, das quais se resumem de
seguida as mais importantes.
O DOORS um repositrio de objectos desenhado para suportar a criao de aplicaes de trabalho
em grupo tipicamente assncrono. Uma das principais caractersticas deste sistema consiste na possibi-
lidade de denir solues especcas de gesto de dados partilhados usando diferentes estratgias em
diferentes tipos de dados. Para tal, deniu-se o framework de componentes DOORS, que decompe o
funcionamento de um objecto em vrios componentes. Cada componente lida com um aspecto especco
da gesto de dados partilhados, entre os quais se destacam, a reconciliao e o tratamento da informao
sobre a evoluo dos dados e da actividade cooperativa. Os programadores podem criar uma soluo
global de gesto de dados com base num conjunto de solues pr-denidas para cada um dos problemas
identicados. O framework de componentes denido uma contribuio original do sistema DOORS.
O sistema DOORS prope igualmente um modelo de integrao de sesses de trabalho sncrono de
curta durao no mbito de uma sesso assncrona de longa durao, no qual se podem usar as tcnicas de
gesto de dados (por exemplo, reconciliao) adequadas a cada um dos modos. Ao contrrio da genera-
lidade dos sistemas de suporte ao trabalho cooperativo, este modelo lida explicitamente com o problema
da diferena de granularidade entre as operaes sncronas e assncronas em algumas aplicaes.
O Mobisnap um sistema de gesto de bases de dados relacional para ambientes de computao
mvel. Neste sistema, os utilizadores modicam a base de dados atravs da submisso de pequenos
programas escritos em PL/SQL, a que se chamam transaces mveis. O cdigo das transaces mveis
12.1. SUMRIO 195
executado no cliente e no servidor, o que permite denir regras de deteco e resoluo de conitos
que explorem a informao semntica associada operao (e s intenes do utilizador).
O Mobisnap integra um mecanismo de preveno de conitos baseado na utilizao de reservas. Este
mecanismo permite garantir o resultado das transaces mveis de forma independente. Relativamente
a propostas anteriores, o mecanismo de reservas apresenta as seguintes contribuies. Primeiro, integra
vrios tipos de reservas, o que se demonstrou ser fundamental para garantir o resultado de um grande n-
mero de transaces. Segundo, o sistema verica de forma transparente se possvel garantir o resultado
de uma transaco mvel com base no seu cdigo e nas reservas disponveis localmente. Esta proprie-
dade permite explorar todas as reservas para garantir qualquer transaco sem que exista necessidade de
modicar a forma como estas so escritas. Terceiro, implementa o mecanismo de reservas num sistema
baseado em SQL e de forma integrada com o modelo de execuo das transaces mveis, permitindo
denir um modelo integrado que combina tcnicas de preveno e resoluo de conitos.
Resultados obtidos por simulao mostram que o mecanismo de reservas permite suportar a opera-
o independente numa aplicao de suporte a uma fora de vendas mvel. Mesmo usando estratgias
simples na obteno de reservas, possvel garantir, de forma independente, mais de 80% das encomen-
das submetidas no pior cenrio estudado, em que no existe previso das encomendas a receber e os
vendedores no obtm reservas inicialmente.
Nesta dissertao descreve-se ainda um novo sistema genrico de reconciliao de transaces m-
veis, o sistema SqlIceCube. Este sistema usado quando necessrio executar um conjunto de transac-
es mveis no servidor do sistema Mobisnap. No SqlIceCube, a reconciliao vista como um pro-
blema de optimizao que consiste em determinar a melhor sequncia de transaces mveis que podem
ser executadas com sucesso. Em particular, a reconciliao vista como um problema de planeamento
em vez de um problema de resoluo de restries (binrias), como acontecia no sistema IceCube [134],
seu antecessor. Esta aproximao permite lidar de forma correcta com pares de transaces cujos efei-
tos se anulam. Esta nova aproximao obrigou a denir um novo conjunto de relaes para exprimir a
informao semntica em problemas de reconciliao. Este sistema inclui ainda um mecanismo original
de extraco automtica de informao semntica a partir do cdigo das transaces mveis. Este meca-
nismo o primeiro a inferir automaticamente a informao necessria reconciliao a partir do cdigo
das operaes e fundamental para permitir a submisso de transaces mveis genricas.
A implementao do sistema Mobisnap descrita nesta dissertao, como uma camada de sistema
intermdia (middleware), representa uma aproximao evolutiva computao mvel. Assim, as aplica-
es que executam o sistema Mobsnap podem utilizar as novas funcionalidades enquanto se permite que
as aplicaes legadas continuem a aceder directamente base de dados central sem nenhuma modica-
o. Adicionalmente, os mecanismos de reservas e reconciliao integrados no sistema so totalmente
196 CAPTULO 12. CONCLUSES
independentes, o que permite a sua utilizao isolada noutros sistemas de suporte computao mvel.
12.2 Trabalho futuro
O trabalho realizado nesta dissertao, alm das contribuies descritas anteriormente, revelou um con-
junto de possveis direces para trabalho futuro. Nesta seco apresentam-se algumas dessas direces
(algumas das quais j foram indicadas ao longo da dissertao).
No mbito do sistema DOORS, est-se a explorar a possibilidade de usar um suporte lingustico
mais adequado na denio de novos coobjectos, com base na linguagem ComponentJ [153]. Esta
aproximao deve permitir uma maior clareza na criao de coobjectos, com a separao da denio
e composio dos componentes. Adicionalmente, deve permitir denir esqueletos de coobjectos que
agrupam um conjunto de componentes para implementar uma dada soluo de gesto de dados. Este
trabalho est a ser desenvolvido no mbito do projecto Databricks[36].
Relativamente ao sistema de reservas implementado no sistema Mobisnap, necessrio avaliar o seu
desempenho em diferentes cenrios e estudar a possibilidade de estender o conjunto de reservas propos-
tas. Uma direco que se pretende explorar a possibilidade de denir reservas que forneam garantias
probabilsticas sobre o estado da base de dados, as quais devem permitir obter garantias igualmente
probabilsticas sobre o resultado nal das transaces mveis.
Adicionalmente, necessrio investigar o impacto da implementao do sistema de reservas no ser-
vidor central da base de dados (no cliente o desempenho no um problema). No mbito desta avaliao
deve considerar-se igualmente o custo de uma implementao integrada no sistema de base de dados.
Outro problema importante a denio de algoritmos genricos de obteno de reservas. Este pro-
blema pode ser visto como uma extenso do problema do replicao antecipada, no qual no se pretende
apenas identicar os dados que vo ser acedidos, mas tambm o modo como vo ser modicados. Um
soluo a explorar consiste em inferir as necessidades de cada utilizador com base na combinao do seu
comportamento anterior e de indicaes explicitamente fornecidas pelo utilizador.
O mecanismo de reconciliao de mltiplas transaces do sistema Mobisnap est ainda sob desen-
volvimento. Em particular, continua a analisar-se a melhor forma de implementar algumas das extenses
referidas na seco 10.5.4.
Uma ltima direco de trabalho futuro a considerar a integrao de um mecanismo de controlo de
divergncia no sistema Mobisnap (estendendo, por exemplo, ideias apresentadas anteriormente [6, 173]).
Este mecanismo deve permitir denir mtricas de divergncia entre a cpia local e central de uma base de
dados adequadas a diferentes aplicaes. Com base nestas mtricas, o sistema deve fornecer mecanismos
que permitam controlar a divergncia admissvel. A integrao destas mtricas com o sistema de reservas
constitui um desao adicional.
Apndice A
DOORS
Este apndice apresenta, de forma detalhada, a implementao executada no prottipo do sistema DO-
ORS do mecanismo de gesto da liao dos servidores que replicam um volume e o mecanismo de
sincronizao epidmica das rplicas dos volumes. Estes mecanismos so essenciais para o funciona-
mento do ncleo do sistema DOORS e garantem que, em todos os servidores correctos que replicam um
volume, sero conhecidas todas as operaes submetidas em todos os coobjectos do volume.
A.1 Filiao
A.1.1 Coobjecto de liao
O coobjecto de liao mantm, em cada volume, a informao sobre o conjunto de servidores que
replica o volume. Este coobjecto dene trs operaes de modicao, executadas em consequncia
dos protocolos estabelecidos para o incio e cessao da replicao de um volume: insero de um novo
servidor; remoo de um servidor; e eliminao das referncias relativas a um servidor anteriormente
removido.
O funcionamento do coobjecto de liao garante que duas rplicas que tenham conhecimento do
mesmo conjunto de operaes esto no mesmo estado (i.e., na mesma vista). Garante-se ainda que o
identicador da vista identica univocamente uma vista, i.e., a cada conjunto distinto/idntico de ope-
raes corresponde um identicador de vista distinto/idntico. Estas propriedades so obtidas como se
explica de seguida.
Cada servidor i que pertence ao grupo de replicadores tem associado um identicador nico srv
vol
1
.
As operaes do coobjecto de liao, submetidas num dado servidor, so identicadas univocamente
1
Este identicador gerado quando o servidor solicita a insero no grupo de replicadores do volume e identica univo-
camente uma presena do servidor no grupo de replicadores este identicador obtido como (srv
global
, id
unico
) a partir do
identicador global do servidor, srv
global
.
197
198 APNDICE A. DOORS
com um par (srv
vol
, n_seq), em que n_seq um nmero inteiro maior do que o n_seq atribudo a qualquer
outra operao conhecida localmente.
Oestado do coobjecto de liao constitudo por umconjunto, M, de triplos (srv
vol
, srv
view
, estado),
em que srv
vol
o identicador nico do servidor (como explicado anteriormente), srv
view
o identica-
dor do servidor na vista denida pelo estado actual do coobjecto de liao do volume ( um nmero
inteiro maior do que zero) e estado tem o valor activo, caso o servidor pertena ao grupo de replicadores,
ou removido, caso o servidor tenha sido removido do grupo de replicadores (usa-se M
i
para designar o
valor de M na rplica do coobjecto de liao do servidor i). O estado inicial do coobjecto de liao
contm apenas a informao relativa ao servidor no qual o volume foi criado (M ={(id
srv
, 1, activo)}).
Seja O o conjunto de operaes reectidas no estado do coobjecto de liao. Um sumrio destas
operaes denido atravs de um vector-verso v, em que v[i] = n
max
, tal que, dado (id, i, _) M
(com _ a designar qualquer valor possvel)), se tem n
max
= max({n : o O ident(o) = (id, n)}
n : o O ident(o) = (_, n) o = insert(id)), com ident(o) o par com que a operao o foi identicada
(ou seja, cada posio, i, reecte o maior n_seq das operaes executadas que foram identicadas pelo
servidor com identicador i na vista actual ou o n_seq da operao que o inseriu no grupo de replicado-
res). Se o identicador local i no estiver atribudo a nenhum servidor v[i] = (com > n, n N). De
forma idntica dene-se o vector verso das operaes que modicam a liao, considerando apenas o
conjunto das operaes que tm inuncia directa na liao insero, remoo e eliminao.
O estado do coobjecto de liao num servidor obtido considerando todas as operaes conhe-
cidas localmente para as quais no existam operaes anteriores submetidas no mesmo servidor que
no sejam conhecidas (ou seja, considerado o seguinte conjunto de operaes: {op : ident(op) =
(id
i
, n_seq) op
1
: ident(op
1
) = (id
j
, n_seq
1
) id
i
= id
j
n_seq > n_seq
1
}, com ident(o) o identi-
cador atribudo operao o). O mecanismo de propagao epidmico de operaes (o nico usado para
propagar operaes do coobjecto de liao) garante esta propriedade para todas as operaes conhecidas
localmente.
A ordem total pela qual estas operaes so executadas em todas as cpias do coobjecto a seguinte.
A partir do estado inicial, as operaes so executadas sequencialmente escolhendo em cada iterao a
operao com menor n_seq. Entre as operaes com igual n_seq, escolhe-se aquela que tenha associado
o identicador de servidor com menor identicador local na vista denida actualmente.
A execuo da operao de insero de um servidor no grupo de replicadores do volume insere o
trio (id
new
, pos
new
, activo) em M, sendo id
new
o identicador gerado para identicar o novo servidor
no grupo de replicadores e pos
new
o menor nmero inteiro maior do que zero que no usado como
identicador de outro servidor na vista actual. A cpia inicial do coobjecto de liao no novo servidor
reecte sempre a execuo da operao que o inseriu no grupo de replicadores.
A.1. FILIAO 199
A operao de remoo de um servidor apenas altera o estado no trio que representa esse servidor
em M. A operao de eliminao das referncias de um servidor remove o trio respectivo do conjunto
M.
A garantia da igualdade entre o estado de duas rplicas de um coobjecto de liao que conheam
o mesmo conjunto de operaes (propriedade de segurana) resultado de: (1) serem executadas todas
as operaes conhecidas; (2) as operaes serem executadas pela mesma ordem total; e (3) as operaes
serem deterministas.
A propagao das operaes de modicao entre as vrias rplicas garante que todas as rplicas do
coobjecto de liao evoluem para o mesmo estado comum (propriedade de evoluo contnua).
O sumrio das operaes que modicam a liao usado como identicador da vista. O algoritmo
optimista usado para executar as operaes pode levar a que o mesmo identicador seja (temporari-
amente) usado em cpias diferentes para identicar servidores diferentes (por exemplo, quando dois
servidores entram concorrentemente no grupo de replicadores usando patrocinadores diferentes). No
entanto, como se explica de seguida, o identicador da vista identica univocamente uma vista.
Sejams
i
e s
j
as sequncias de operaes que modicama liao executadas nas cpias i e j do coob-
jecto de liao (a partir do mesmo estado inicial). Se s
i
=s
j
, a igualdade das cpias i e j garante a igual-
dade dos identicados da vista. Se s
i
=s
i
, possvel decompor s
i
s
comum
, op
i
, s f
i
e s
j
s
comum
, op
j
, s f
j
em que s
comum
o maior prexo (eventualmente nulo) de operaes comuns (s f
i
e s f
j
podem ser sequn-
cias nulas e op
j
pode representar a ausncia de uma operao se s f
j
for a sequncia nula).
Vamos supor, sem perda de generalidade, que op
i
anterior a op
j
na ordem total pela qual as opera-
es so executadas, e ident(op
i
) = (srv
k
, n). Aps executar s
comum
, tem-se (srv
k
, m, _) M em ambos
as cpias do coobjecto de liao.
O trio associado a srv
k
existe necessariamente em M pelas seguinte razes. Primeiro, impossvel
ser conhecida uma operao submetida num servidor antes da operao de insero porque: a cpia do
coobjecto de liao no novo servidor iniciada a partir da cpia do patrocinador que j reecte o novo
servidor; as operaes submetidas no novo servidor so identicadas com um n_seq superior ao n_seq da
operao que o inseriu no grupo de replicadores; e as operaes so propagadas entre servidores usando
um mecanismo de propagao epidmica (que propaga as operaes por ordem de n_seq). Segundo,
impossvel a entrada do servidor ter sido eliminada porque uma entrada apenas eliminada quando todas
as operaes relativas a esse servidor foram executadas em todos os servidores.
Assim, aps a execuo da sequncia de operaes s
i
, tem-se necessariamente v[m] n
2
. Por outro
2
Note que, se o servidor associado a m, srv
m
, tiver sido removido, se tem: v[m] =>n se a posio no tiver sido reutilizada
por outro servidor, ou v[m] >n se a posio tiver sido reutilizada porque a operao de insero do novo elemento no grupo
ter de ter sempre um n_seq superior ou igual ao n_seq da operao de remoo do servidor (ou ser-lhe-ia atribudo um diferente
identicador na vista), a qual por sua vez ter de ter sempre um n_seq superior a n (pelo modo como as operaes de remoo
lado, na cpia j, tem-se necessariamente v[m] < n, porque a execuo de op
j
, posterior a op
i
, impede
esta de ser executada (e a ordem denida garante que nenhuma outra operao submetida no servidor
identicado por m pode ser executada). Nesta cpia, impossvel que o servidor associado a m tenha
sido removido (porque o modo de funcionamento do coobjecto garante que uma operao de remoo
apenas executada aps a execuo de todas as operaes submetidas nesse servidor). Desta forma, a
execuo de dois conjuntos diferentes de operaes leva a que o identicador da vista seja igualmente
diferente.
A.1.2 Protocolo local de mudana de vista
O protocolo local de mudana de vista executado localmente num servidor sempre que necessrio
modicar o estado do coobjecto de liao. Este protocolo executa, de forma atmica, as actualizaes
necessrias nos identicadores dos servidores usados em todos os coobjectos do volume. No m da
execuo do protocolo diz-se que foi instalada a vista denida pelo coobjecto de liao.
O protocolo local de mudana de vista consiste nos seguintes passos executados no servidor i, dado
um conjunto de operaes a executar sobre o coobjecto de liao:
1. Qualquer acesso cpia do volume no servidor i impedido (incluindo os acessos aos coobjectos
pertencentes a esse volume).
2. So executadas as operaes desejadas no coobjecto de liao (que podem incluir operaes
recebidas de outro servidor). O estado nal do coobjecto dene a nova vista que vai ser instalada
na cpia do volume.
3. Se um novo identicador de vista foi denido (i.e., se foi executada alguma operao que al-
tere a liao), todos os coobjectos so informados da nova vista e das mudanas necessrias
para converter os identicadores antigos nos novos. Normalmente, os identicadores j existentes
mantm-se e no necessrio executar nenhuma aco nos coobjectos.
4. O protocolo termina e permite-se, de novo, o acesso cpia do volume.
Se durante a execuo do protocolo existir alguma falha no servidor, o protocolo volta a ser reiniciado
no ponto onde falhou. As falhas na execuo do protocolo so detectadas da seguinte forma. O incio
do protocolo registado em memria estvel, onde se guarda a data de incio aps a concluso do
protocolo esta informao removida. Quando um servidor reiniciado, qualquer registo de incio do
protocolo na memria estvel corresponde a uma execuo no terminada. Uma falha durante o passo 2
detectada pelo facto de o estado do coobjecto de liao guardado em memria estvel ter uma data
so submetidas).
A.1. FILIAO 201
anterior de incio de protocolo. A deteco de falhas durante a execuo do passo 3 efectuada de
forma idntica para cada coobjecto.
A.1.3 Protocolo de entrada no grupo de replicadores de um volume
O protocolo de entrada no grupo de replicadores de um volume controla a entrada de um novo servidor
no grupo de servidores que replicam um volume. Nesta situao, necessrio actualizar o coobjecto de
liao e propagar um cpia do volume para o novo servidor.
O protocolo de entrada no grupo de replicadores de um volume v do servidor i, tendo como patroci-
nador o servidor j pertencente ao grupo de replicadores de v, tem os seguintes passos:
1. i comunica a j o desejo de entrar no grupo e indica-lhe o identicador nico que usar id
i
. At
concluso do protocolo, o servidor j ca impedido de participar em protocolos de remoo
voluntria do grupo de replicadores.
2. O servidor j executa o protocolo local de mudana de vista no volume v usando a operao de
insero no grupo do servidor i com identicador nico id
i
.
3. O servidor j envia para o servidor i o estado actual da sua cpia do volume durante uma sesso de
sincronizao epidmica, incluindo uma cpia de todos os coobjectos existentes quando uma
cpia de um coobjecto instanciada pela primeira vez num servidor, executada uma operao
na interface do coobjecto a informar o coobjecto dessa situao. Aps a recepo do coobjecto de
liao, o servidor i pode iniciar imediatamente a sua operao (embora se espere pela recepo
de todo o estado do volume, a menos que exista alguma falha).
Se durante a execuo do protocolo existir alguma falha, o protocolo reiniciado, reexecutando o
passo em que falhou as falhas no passo 2 so resolvidas como explicado anteriormente. As falhas
durante a propagao do estado do volume so resolvidas atravs da execuo de uma nova sesso de
sincronizao epidmica.
A.1.3.1 Condies sucientes para a ordenao correcta de operaes usando tcnicas de veri-
cao da estabilidade da ordem
Quando um novo servidor se junta ao grupo de replicadores de um volume, o seu identicador provi-
srio at se garantir que a operao de insero executada no coobjecto de liao no ser desfeita no
futuro. Assim, quando se usam as tcnicas de estabilidade descritas na seco 4.1, no se deve usar a
informao relativa aos servidores que tm identicadores provisrios
3
.
3
O identicador de um servidor adicionado ao grupo de replicadores de um volume pela operao de adio com identica-
dor (srv
vol
, n_seq) provisrio sse essa operao de adio ainda no foi ordenada de forma denitiva na rplica do coobjecto
Adicionalmente, para garantir que as operaes so ordenadas correctamente, em cada um dos coob-
jectos, a primeira operao submetida no novo servidor deve ter nmero de sequncia igual ou superior
a max +2, com max o valor do maior nmero de sequncia que o novo servidor sabe ter sido usado em
qualquer rplica.
Relativamente aos servidores conhecidos, a vericao da estabilidade garante que as operaes
so executadas pela sua ordem correcta. Assim, apenas seria possvel executar uma operao fora
de ordem, executando num qualquer servidor uma operao, op
1
, de um servidor conhecido que de-
vesse ser ordenada aps uma operao, op
2
, submetida num novo servidor ainda no conhecido. Como
seq(op
2
) max+2, ento necessariamente seq(op
1
) max+2. No entanto, para ordenar uma operao
com nmero de sequncia max +2, um servidor tem de receber informao de todos os servidores que
no existe mais nenhuma operao com nmero de sequncia max +1. Para tal, necessrio contactar
o patrocinador da juno ao grupo do novo servidor (porque no momento da juno ao grupo, no patro-
cinador, apenas se tinham usado nmeros de sequncia inferiores ou iguais a max). Como no contacto
com o patrocinador, o servidor vai ser informado da existncia do novo servidor, ele tem de considerar
a informao recebida do novo servidor antes de ordenar a operao op
1
. Como a informao do novo
servidor no pode ser usada enquanto a posio do servidor na vista local no estvel, um servidor
no pode executar nenhuma operao op : seq(op) = max +2 enquanto a posio do novo servidor no
estvel, porque necessita de usar a informao que no existe nenhuma operao nesse servidor com
nmero de sequncia igual a max +1. Assim, as operaes com nmero de sequncia max +2 apenas
so executadas quando o nmero de sequncia do novo servidor est estvel, o que garante a correco
da ordenao das operaes.
A.1.4 Protocolo de sada voluntria do grupo de replicadores de um volume
O protocolo de sada voluntria do grupo de replicadores de um volume controla a sada voluntria de
um servidor do grupo de servidores que replicam um volume. Nesta situao, necessrio que no se
perca nenhuma informao que se encontre apenas nesse servidor (i.e., operaes relativas a coobjectos
do volume, incluindo o coobjecto de liao, que apenas sejam conhecidas nesse servidor). Adicional-
mente, a liao do grupo de replicadores deve ser actualizada e os recursos usados para replicar esse
volume devem ser libertos.
Quando o servidor que pretende cessar a replicao de um volume o nico que replica o volume (de
acordo com o estado do coobjecto de liao nesse servidor), o servidor limita-se a libertar os recursos
de liao, i.e., sse existe pelo menos um servidor activo, srv2
vol
, do qual pode existir um operao ainda desconhecida com
nmero de sequncia n_seq
2
, em que n_seq
2
n_seq nos casos em que o identicador de srv2
vol
na vista actual inferior ao
identicador de srv
vol
, ou n_seq
2
<n_seq nos outros casos.
A.1. FILIAO 203
associados e o volume deixa de existir. Caso contrrio, o servidor deve seleccionar outro servidor que
replique o volume como patrocinador para a sua aco, e efectuar o protocolo de sada do grupo.
O protocolo de sada do grupo de replicadores de um volume v do servidor i, tendo como patrocina-
dor o servidor j pertencente ao grupo de replicadores, tem os seguintes passos:
1. i coloca-se no estado de pr-removido em relao ao volume e no executa mais nenhuma operao
relativa a esse volume (i.e., no participa em sesses de sincronizao nem aceita pedidos de
clientes).
2. i informa j que pretende sair do grupo de replicadores do volume v e que pretende que j seja o seu
patrocinador. Se j no aceitar, i deve escolher um novo patrocinador.
3. Caso j aceite ser patrocinador de i, o protocolo continua e j ca impedido de sair do grupo de
replicadores do volume at que o protocolo de sada de i termine.
4. i informa todos os coobjectos do volume (conhecidos em i) que esse servidor vai ser removido e
o patrocinador da remoo j, usando, para tal, uma operao denida na interface do coobjecto
(em consequncia desta informao os coobjectos podem efectuar as operaes necessrias para a
continuao normal da sua operao por exemplo, em coobjectos que denam uma cpia como
principal, caso a cpia a remover seja a principal, pode executar-se uma operao que transfere
esse estatuto para a cpia de j).
5. j informa todos os coobjectos do volume (conhecidos em j) que o servidor i vai ser removido,
usando, para tal, uma operao denida na interface do coobjecto (em consequncia desta infor-
mao, os coobjectos podem efectuar as aces necessrias ao seu correcto funcionamento).
6. i estabelece uma sesso de sincronizao de todos os coobjectos incluindo o coobjecto de -
liao com o servidor j. Nesta sesso de sincronizao, i tambm recebe as novas operaes
conhecidas em j, podendo executar as operaes necessrias para o bom funcionamento do coob-
jecto (como se exemplica, por exemplo, no apndice A.1.8).
7. Aps a concluso bem sucedida da sesso de sincronizao, o servidor j executa o protocolo local
de mudana de vista executando a operao de remoo respectiva. O servidor i liberta os recursos
usados pelo volume v.
Se durante a execuo do protocolo existir alguma falha, o protocolo reiniciado executando nova-
mente o passo em que o protocolo falhou. O passo 6 garante que nenhuma operao perdida durante a
remoo voluntria dum servidor do grupo de replicadores de um volume.
Para que no se perca informao pela sada voluntria de um servidor do grupo de replicadores
necessrio que este propague toda a informao que mantm para outro elemento do grupo de replica-
dores. No caso de a sada ser patrocinada por outro servidor, esta propriedade garantida pela sesso
de sincronizao que estabelecida durante o respectivo protocolo. As sadas no patrocinadas apenas
acontecem no caso de no existir mais nenhum servidor que replique o volume.
A.1.5 Operao de disseminao e execuo
Em alguns dos protocolos que se apresentam de seguida necessrio garantir que apenas se executa
uma dada aco aps todos os coobjectos do volume nesse servidor receberem as operaes conhecidas
num dado conjunto de servidores num dado momento. Por exemplo, aquando da falha denitiva de
um servidor, apenas se podem executar as operaes que levam remoo desse servidor do grupo de
replicadores do volume, aps se conhecerem todas as operaes submetidas no servidor a remover.
Para garantir esta propriedade, cada servidor necessita de manter informao sobre quais os ou-
tros servidores dos quais conhece o estado (i.e., os servidores dos quais recebeu o estado aps ter sido
executada uma dada operao). Esta informao mantida pelo coobjecto de liao no protocolo de
disseminao e execuo que se descreve de seguida.
Anncio de incio do protocolo Quando se pretende executar a operao op aps todos os coobjectos
do volume reectirem as operaes conhecidas actualmente no conjunto de servidores S, submete-se a
operao disseminate(uid, S, op, cond) no coobjecto de liao, com uid um identicador nico para
este pedido de disseminao e cond uma funo que verica se as condies de disseminao do pedido
se encontram satisfeitas. A execuo desta operao num servidor d incio execuo do protocolo de
disseminao e execuo.
Informao de disseminao Cada rplica do coobjecto de liao mantm, para cada pedido de dis-
seminao pendente, a informao (uid, S, op, cond, v, Gc), com: uid, op, cond e S os valores anteriores;
v uma matriz de nmeros inteiros tal que v[i, j] = n indica que se sabe que i reecte o estado de j aps
a execuo da operao de disseminao e num momento em que, no servidor j, j tinha sido execu-
tada a operao submetida em j com nmero de sequncia n; e Gc um conjunto usado para remover a
informao sobre o pedido de disseminao, inicialmente vazio. Quando a operao de disseminao
executada no servidor i, a informao anterior criada, sendo a matriz v iniciada da seguinte forma:
v[i, i] = n, com n o nmero de sequncia da ltima operao identicada em i; e v[ j, l] = 1 nos ou-
tros casos. Adicionalmente, submete-se a operao disseminated(uid, i, v
i
), explicada de seguida. Esta
informao permite informar todos os replicadores do volume do estado reectido pela rplica i.
A.1. FILIAO 205
Actualizao da informao de disseminao Quando, aps uma sesso de sincronizao, o servidor
j ca a conhecer todas as operaes conhecidas no servidor i relativas a todos os coobjectos do volume,
j submete no coobjecto de liao, aps executar todas as operaes do coobjecto de liao recebidas,
para cada pedido de disseminao pendente, a operao disseminated(uid, j, v
i
), com v
i
o valor do vector
v[i] da matiz v associada ao pedido de disseminao que se est a considerar, com excepo de v
i
[ j] = n
j
com n
j
o nmero de sequncia da ltima operao identicada em j.
Esta operao indica que j conhece todas as operaes conhecidas em i no momento em que se
iniciou o protocolo de disseminao e execuo, assim como todas as operaes conhecidas noutros
servidores que entretanto tenham sido propagadas para i.
A execuo desta operao, em qualquer servidor, leva actualizao da informao relativa ao
servidor j na matriz local v: n, v[ j, n] = max(v[ j, n], v
i
[n]).
A correco do funcionamento desta operao resulta da correco do valor v[i] aquando da sub-
misso da operao. Esta correco resulta de se submeter uma operao disseminated no incio do
protocolo e sempre que se actualiza v, e de executar as operaes recebidas num servidor antes de sub-
meter a operao disseminated.
Condio de execuo da operao (cond) Por omisso (cond = null), a operao op, relativa a um
pedido de disseminao, ser executada, no servidor l, quando for possvel determinar que l reecte todas
as operaes conhecidas no conjunto de servidores S. Esta condio verica-se quando n S, v[l, n] =
1.
Se um servidor, i, pertencente ao conjunto S, tiver sido removido do grupo de replicadores por uma
operao submetida no servidor j (i.e., j foi o patrocinador da remoo de i) e identicada com nmero
de sequncia nr
i
, deve ter-se v[l, i] = 1 v[l, j] nr
i
(o protocolo de remoo de um servidor garante
que, quando a operao de remoo executada no patrocinador, o patrocinador reecte o estado do
servidor removido). Se o servidor j que foi patrocinador da remoo de i tiver igualmente sido removido,
tendo como patrocinador k, atravs duma operao submetida em k com nmero de sequncia nr
j
, deve
ter-se v[l, i] = 1v[l, j] nr
i
v[l, k] nr
j
. De forma semelhante para outras eventuais remoes de
servidores.
Reciclagem Quando o servidor i executa a operao op, submete a operao end
dissemination
(uid, i),
indicando que o servidor i no necessita de informao adicional relativa ao pedido de disseminao uid.
Quando esta operao executada num servidor, o conjunto Gc associado ao pedido de disseminao uid
actualizado da seguinte forma Gc Gc {i}. Quando, num servidor, Gc incluir todos os servidores
activos da vista denida pelo coobjecto de liao, a informao relativa ao pedido de disseminao
removida.
Optimizaes Em relao a esta descrio existe algumas uma optimizao simples: na matriz v ape-
nas necessrio manter as entradas relativas aos servidores contidos em S (e, no caso de um desses
servidores ter sido removido, dos servidores que foram os seus patrocinadores, como se explicou anteri-
ormente). Adicionalmente, seria possvel usar apenas uma matriz v para todos os pedidos de dissemina-
o pendentes, com as modicaes apropriadas no comportamento das operaes.
Existe um caso especial para esta operao a situao em que se pretende a disseminao entre
todos os servidores do estado actual de todas as cpias do volume. Neste caso, o servidor que submete a
operao do pedido de disseminao pode no ter conhecimento de todos os servidores que actualmente
replicam o volume. Assim, impossvel, quando a operao submetida, determinar exactamente o
valor de S. Por isso, usa-se o valor especial S =U. Neste caso, a operao op ser executada no servidor
i no momento em que, de acordo com a vista actualmente denida localmente, se tiver informao que
o estado de todos os servidores activos ou removidos est reectido na cpia actual do servidor, i.e: (1)
para todo o servidor j activo se tem v[i, j] = 1; (2) para todo o servidor j removido com patrocinador
k e nmero de sequncia da operao nr
j
se tem v[i, j] = 1 v[i, k] nr
j
(e de forma semelhante ao
apresentado anteriormente no caso de o patrocinador ter sido igualmente removido).
A.1.6 Protocolo de eliminao do identicador de um servidor removido
O protocolo de eliminao do identicador de um servidor removido tem por objectivo garantir que o
identicador do servidor removido apenas eliminado quando no necessrio ao bom funcionamento
de nenhum coobjecto, ou seja, quando as operaes do servidor removido tiverem sido propagadas e
denitivamente processadas em todos os servidores. A eliminao de um identicador permite que o
mesmo seja utilizado por um novo replicador.
O protocolo de eliminao do identicador de um servidor removido, i, iniciado pelo patrocinador
da remoo, j, e consiste nos seguintes passos:
O patrocinador, j, da remoo do servidor i, aps submeter a operao de remoo, submete a
operao disseminate(uid, {j}, askEliminate(i), null). Desta forma, garante-se que a operao
askEliminate apenas executada num servidor aps se conhecerem nesse servidor todas as opera-
es conhecidas actualmente em j relativas a todos os coobjectos (e, emconsequncia do protocolo
de remoo, todas as operaes que foram submetidas em i).
O coobjecto de liao mantm, para cada identicador i que se pretende eliminar, o par (i, R), em
que R contm o conjunto de servidores que deram a sua concordncia eliminao de i.
A execuo da operao askEliminate(i) num servidor l, leva introduo do par (i, {}) na infor-
mao sobre os identicadores a eliminar.
A.1. FILIAO 207
Periodicamente, cada servidor l verica se pode eliminar algum identicador que esteja no con-
junto de identicadores a eliminar (e para o qual ainda no tenha dado a sua concordncia). Para
tal, pergunta-se a todos os coobjectos do volume se eles concordam com a eliminao do identi-
cador, usando uma funo denida na interface do coobjecto. Em geral, um coobjecto apenas
se ope remoo de um identicador quando as operaes submetidas no servidor que tinha
esse identicador ainda no tiverem sido executadas de forma estvel na cpia local do coob-
jecto. Se nenhum coobjecto se opuser remoo do identicador, o servidor l submete a operao
canEliminate(i, l) no coobjecto de liao a execuo desta operao em qualquer servidor
leva introduo de l no conjunto R de servidores que deram a sua concordncia eliminao de
i.
Quando qualquer servidor l detecta que todos os servidores activos na vista corrente deram o
seu acordo eliminao de um identicador i (usando o conjunto R), ele submete a operao
eliminate(i). A execuo desta operao, em qualquer servidor, leva remoo da informao
associada ao servidor identicado por i e libertao do respectivo identicador local (assim como
remoo da informao associada a i no conjunto de identicadores a remover). A submisso
concorrente desta operao por mais do que um servidor no pe problemas para a correco do
funcionamento do sistema (a ordenao total das operaes leva a que as rplicas convirjam para o
mesmo estado e que apenas a primeira operao de eliminao tenha efeitos no estado do coobjecto
de liao).
A.1.7 Protocolo de sada forada do grupo de replicadores de um volume
O protocolo de sada forada do grupo de replicadores de um volume controla a remoo forada de
um servidor do grupo de replicadores do volume. Esta operao necessria quando, por exemplo, um
servidor cou danicado e a memria estvel na qual estava armazenado o estado dos coobjectos do
volume irrecupervel.
Estratgia O funcionamento dos coobjectos obriga a que se informem todos os coobjectos do volume
sobre a remoo do servidor. No entanto, os coobjectos apenas devemser noticados aps se conhecerem
todas as operaes submetidas no servidor a remover
4
(e identicadas com um nmero de sequncia e o
identicador desse servidor) na remoo voluntria, o servidor que vai ser removido encontra-se nesta
4
Por exemplo, quando um coobjecto ordena totalmente as operaes usando tcnicas baseadas na vericao da estabilidade
da ordem importante saber qual o valor do nmero de sequncia da ltima operao identicada por cada servidor removido,
por forma a permitir a correcta ordenao de todas as operaes dos servidores removidos e a expedita ordenao das operaes
originadas noutros servidores.
situao e pode informar os coobjectos. Para que estas condies se veriquem foi adoptada a seguinte
estratgia para a remoo forada de um servidor:
1. Um qualquer servidor pode efectuar o pedido de remoo forada de um outro servidor j. No
caso de mais do que um servidor pedir concorrentemente a remoo do mesmo servidor j, ape-
nas o pedido que executado primeiro (segundo uma ordem total denida entre estes pedidos)
considerado.
2. Cada servidor indica a sua concordncia (ou discordncia) na remoo do servidor (no caso da
remoo ser motivada pela inacessibilidade ao servidor, cada servidor pode tomar a sua deciso
em funo de conseguir aceder ao servidor ou no). A partir do momento em que um servidor i
concorda com a remoo forada do servidor j, i no pode executar mais nenhuma comunicao
(sesso de sincronizao) com j. Se qualquer servidor mostrar a sua discordncia na remoo
do servidor j, o pedido de remoo forada abortado (e todos os servidores podem voltar a
comunicar com j).
3. Concorrentemente, fora-se a disseminao entre todos os servidores do estado actual de todos
os coobjectos (por forma a que sejam conhecidas todas as operaes identicadas pelo servidor a
remover).
4. Em cada momento, dene-se um nmero de ordem para cada servidor que replica um dado volume
(denido pela ordem de entrada no volume segundo a ordem total denida para as operaes de
liao e considerando apenas os servidores que actualmente replicam o volume).
5. A remoo forada de um servidor j pode prosseguir se o servidor com menor nmero de ordem
vericar que: (1) todos os servidores do volume, com excepo do servidor j, concordaram com
a remoo (ou seja, mais nenhuma servidor aceitar comunicaes de j); e (2) o estado actual do
servidor reecte os estados de todos os servidores no momento em que eles executaram a operao
de concordncia com a remoo (ou seja, o estado actual reecte todas as operaes submetidas
por j conhecidas nos servidores que continuaro a replicar o volume dado que mais nenhuma
comunicao com origem em j aceite pelos servidores aps declararem a sua concordncia com a
remoo). Neste caso, no servidor com menor nmero de ordem, informam-se todos os coobjectos
da remoo de j (de forma a que os coobjectos tomem as medidas necessrias remoo segura
do servidor), aps o que se submete a operao de remoo de j no coobjecto de liao (durante
a execuo destas aces, o servidor no efectua comunicaes com outros servidores ou clientes).
Podem existir situaes em que mais do que um servidor necessite de ser removido simultaneamente
ou que o servidor com menor nmero de ordem seja um dos servidores a remover. Para considerar
A.1. FILIAO 209
estas situaes, a ltima condio expressa anteriormente generalizada para (considerando a remoo
conjunta de um conjunto R de servidores, sendo que o conjunto S de servidores no removidos com
U =RS, o conjunto de servidores que replica o volume dene um quorum (neste caso, uma maioria)
no sistema U):
A remoo forada de um conjunto R de servidores pode prosseguir se o servidor com menor n-
mero de ordem, no contido em R, vericar que: (1) todos os servidores do volume, com excepo
dos servidores includos em R, concordaram com a remoo de todos os servidores em R (convm
realar que possvel que alguns servidores em R tenham concordado com a remoo de outros
servidores presentes em R e tenham posteriormente sido alvo de remoo forada); (2) o estado
actual do servidor reecte os estados de todos os servidores no momento em que eles executaram a
ltima operao de concordncia com a remoo de um servidor pertencente a R (ou seja, o estado
actual reecte todas as operaes submetidas pelos servidores em S).
Implementao Para implementar a estratgia descrita anteriormente, deniram-se as seguintes ope-
raes no coobjecto de liao:
askRemove(uid,i) Pede a remoo do servidor i do grupo de replicadores, usando o identicador nico
uid para identicar univocamente o pedido. Esta operao, quando executada, coloca o estado do
servidor i como a_remover(uid) (no caso de o estado j ser a_remover(uid
0
), a operao falha e
submetida a operao rollbackRemove(uid))
5
.
agreeRemove(j,uid) Indica a concordncia do servidor j com o pedido de remoo (do servidor i) com
identicador uid. O coobjecto de liao mantm, para cada pedido de remoo de um servidor, a
lista de servidores que armaram a sua concordncia com essa remoo. Aps a submisso desta
operao, o servidor j no pode retroceder na sua inteno de remover i, nem estabelecer qual-
quer sesso de sincronizao com i, a menos que seja executada uma operao de rollbackRemove
noutro servidor. Um servidor l que inicie a replicao de um volume deve executar a aco agree-
Remove(l,uid) se o seu patrocinador, o servidor j, tiver executado a operao agreeRemove(j,uid)
5
A execuo optimista das operaes no coobjecto de liao pode levar a que a primeira execuo da operao askRe-
move(uid,i) coloque o estado do servidor i como a_remover(uid), enquanto na execuo denitiva se verique que j existe
outro pedido anterior para a remoo do mesmo servidor i esta situao no afecta a correco do funcionamento do sis-
tema, devendo em cada execuo serem executadas as aces indicadas. Quando a execuo optimista da operao desfeita,
o estado associado ao servidor i reposto no estado anterior, mas as operaes submetidas em consequncias da primeira exe-
cuo no so removidas (uma optimizao possvel submeter a operao de rollbackRemove apenas uma vez). A correco
de funcionamento do sistema tambm no afectada se aquando da execuo denitiva, ao contrrio do que aconteceu numa
execuo optimista, o estado do servidor i no for activo as operaes de rollbackRemove(uid) encarregam-se de abortar
este pedido. Neste caso, um novo pedido deve ser efectuado posteriormente.
antes de executar a operao de insero de l no grupo de replicadores do volume. Caso contrrio,
o servidor l pode tomar uma posio independente.
rollbackRemove(uid) Indica que o pedido de remoo (do servidor i) com identicador uid deve ser
cancelado. Aexecuo desta operao recoloca o estado de i emactivo (e permite que os servidores
que tinham dado a sua concordncia com a remoo de i possam voltar a comunicar com i).
readyRemove(uid) Indica que a cpia local do servidor est pronta para concluir o pedido de remo-
o forada. A remoo apenas se executar se os outros servidores tiverem concordado com a
remoo (como se explicou anteriormente).
Usando estas operaes e a operao de disseminao denida anteriormente, a remoo forada de
um servidor i do grupo de replicadores do volume v processa-se da seguinte forma:
1. Um qualquer servidor j, pertencente ao grupo de replicadores do volume v, submete as operaes
askRemove(uid, i) e disseminate(uid
d
, U, readyRemove(uid), readyCond) no coobjecto de lia-
o do volume v. A operao askRemove d incio ao processo de remoo forada de um servidor
a sua execuo com sucesso coloca o estado do servidor em a_remover(uid). A operao de
disseminao garante a propagao das operaes identicadas no servidor i para todos os repli-
cadores do volume.
A condio readyCond verica se as condies para a execuo da operao readyRemove (descri-
tas anteriormente) so satisfeitas, i.e., se todos os servidores que no vo ser removidos concordam
com a remoo e se, para todos os coobjectos, todas as operaes submetidas em i, e conhecidas
em qualquer servidor aquando da execuo da operao agreeRemove, esto reectidas na rplica
local do coobjecto
6
.
Assim, readyCond ser verdadeiro no servidor i, quando: (1) todos os servidores que no vo ser
removidos submeteram a operao agreeRemove respectiva; (2) para todo o servidor activo, j, que
submeteu a operao agreeRemove( j, uid) identicada em j com o nmero de sequncia t
cr
, se
tem v[i, j] t
cr
; (3) para todo o servidor removido j, removido pela operao de remoo sub-
metida no patrocinador k com nmero de sequncia t
r j
, se tem v[i, k] t
r j
7
. Se o servidor k tiver
posteriormente sido removido pela operao de remoo submetida no patrocinador l com nmero
de sequncia t
rk
, deve ter-se v[i, k] t
t j
v[i, l] t
rk
(e de modo semelhante para consecutivas
remoes).
6
O facto de a operao agreeRemove ser executada independentemente da operao de disseminao leva a que a condio
denida por omisso no seja vlida neste caso.
7
Se o servidor removido, j, tiver submetido a operao agreeRemove( j, uid), basta vericar a primeira condio.
A.1. FILIAO 211
2. Um servidor j, no qual o estado do servidor i a_remover(uid), aps executar as vericaes
que considere necessrias, deve submeter a operao agreeRemove( j, uid) ou rollback(uid) se,
respectivamente, concordar ou discordar da remoo do servidor (e, caso concorde, actuar em
conformidade com essa deciso).
3. A execuo da operao readyRemove no servidor i, verica se i o responsvel por efectuar a
remoo, considerando todos os pedidos de remoo pendentes (i.e., se o servidor com menor
nmero de ordem na vista actual dos servidores que no se incluem no conjunto de servidores
prontos a serem removidos). O responsvel pela remoo, actua como patrocinador da remoo e
executa as seguintes operaes (sem permitir acessos concorrentes de outros servidores ou clien-
tes): (1) informa todos os coobjectos do volume quais so os servidores que vo ser removidos;
(2) submete as operaes de remoo respectivas (atravs do protocolo local de mudana de vista).
O mecanismo de remoo forada de um servidor leva a que operaes propagadas por um cliente
para o servidor removido sejam perdidas caso no tenham sido anteriormente propagadas para outro
servidor que permanea no sistema. Assim, este mecanismo apenas deve ser usado em relao aos servi-
dores que se encontram permanentemente desconectados do sistema (por exemplo, devido a terem sido
danicados). Se um servidor removido no estiver permanentemente desconectado, ele deve propagar as
operaes que recebeu de clientes para um servidor que esteja a replicar o volume e, caso pretenda, pedir
a sua insero no grupo de replicadores.
A.1.8 Protocolo de execuo dos blocos s-uma-vez em ordenaes por vericao da
estabilidade
Nos protocolos que ordenam as operaes vericando a estabilidade da ordem (ordem causal sec-
o 4.1.3, ordem total seco 4.1.4.2), quando um servidor sai voluntariamente do grupo de replica-
dores de um volume, o patrocinador assume a responsabilidade de executar os blocos s-uma-vez das
operaes que ainda no tenham sido executadas no servidor removido. No entanto, como o patroci-
nador pode j ter executado algumas das operaes das quais devia executar os blocos s-uma-vez, o
seguinte protocolo usado para garantir que os blocos s-uma-vez so executados uma e uma s vez:
1. Quando a rplica de um coobjecto num servidor informada que esse servidor vai ser removido
do grupo de replicadores (passo 4 do protocolo de remoo), executa uma operao que indica
quais as operaes executadas at esse momento e quais as operaes pelas quais responsvel
por executar os blocos s-uma-vez (neste caso, as operaes recebidas no servidor e aquelas cuja
responsabilidade possa ter sido delegada anteriormente). Esta operao delega no patrocinador a
responsabilidade de executar os blocos s-uma-vez das operaes ainda no executadas.
2. Quando a rplica de um coobjecto num servidor informada que esse servidor vai servir de patro-
cinador remoo de outro servidor (passo 5 do protocolo de remoo), executa uma operao que
indica quais as operaes executadas at esse momento. At concluso da sesso sincronizao
executada no mbito do protocolo de remoo, mais nenhuma operao executada nessa rplica
do coobjecto. Esta operao delega no servidor a remover a responsabilidade de executar os blocos
s-uma-vez das operaes que j foram executadas no patrocinador.
3. Aps a sesso de sincronizao do protocolo de remoo (passo 6), a rplica do coobjecto no
servidor a remover executa todas as operaes que j tenham sido executadas no patrocinador e
pelas quais responsvel por executar os blocos s-uma-vez (para tal, pode ter de executar outras
operaes). A sesso de sincronizao executada garante que no servidor a remover possvel
executar essas operaes.
4. Aps a sesso de sincronizao do protocolo de remoo, a rplica do coobjecto presente no pa-
trocinador retoma a sua execuo normal, i.e., executa todas as operaes possveis. No entanto,
ca responsvel por executar os blocos s-uma-vez de todas as operaes pelas quais o servidor
removido era responsvel e que ainda no tinham sido executadas quer no servidor removido quer
no patrocinador no incio do protocolo (i.e., as operaes cujo nmero de sequncia seja superior
ao mximo dos nmeros de sequncia indicados como executados pelas operaes submetidas nos
passos 4 e 5 deste protocolo).
Quando se processa a remoo forada de um servidor, os blocos s-uma-vez das operaes recebidas
nesse servidor no so executadas emnenhumoutro servidor. Assim, neste caso, no se garante que todos
os blocos s-uma-vez sejam executados.
A.2 Sincronizao epidmica
Os protocolos de sincronizao epidmica so estabelecidos entre pares de servidores para sincronizar
o estado de um conjunto de coobjectos pertencentes a um volume. Durante estas sesses epidmicas os
servidores propagam entre si as operaes que conhecem (independentemente do servidor no qual foram
recebidas). Desta forma, cada servidor recebe, para cada coobjecto, todas as operaes submetidas em
todos os servidores, directa ou indirectamente.
No sistema DOORS foram implementados dois algoritmos de sincronizao. Primeiro, um algoritmo
de sincronizao bilateral, em que dois servidores trocam entre si as novas operaes que conhecem.
Segundo, um algoritmo de sincronizao unilateral que permite a um servidor enviar para outro servidor
as operaes que conhece. Estes algoritmos so apresentados brevemente de seguida uma discusso
A.2. SINCRONIZAO EPIDMICA 213
mais detalhada foi apresentada anteriormente em [125]. Antes de apresentar os algoritmos, descreve-se
a informao utilizada para controlar o seu funcionamento.
A.2.1 Informao utilizada
Em cada cpia do coobjecto mantido um sumrio das operaes conhecidas. Este sumrio repre-
sentado como um vector-verso l, em que, l[i] = n
i
signica que a cpia do coobjecto conhece todas as
operaes identicadas no servidor i comum nmero de sequncia igual ou inferior a n
i
(a cpia do coob-
jecto pode, ainda, conhecer operaes com nmero de sequncia superior a n
i
). Estes sumrios mantm
informao relativa, no s, aos servidores activos, mas tambm, aos servidores removidos ainda no
eliminados. Em cada servidor i, l[i] mantm o valor actual do relgio lgico usado para identicar as
novas operaes nesse servidor a nova operao ser identicada com o nmero de sequncia l[i] +1
e o valor de l[i] ser actualizado para reectir a nova operao (l[i] l[i] +1).
Cada cpia dum coobjecto mantm ainda informao sobre as operaes conhecidas nos outros ser-
vidores. Como se referiu na seco 3.3.2, foram denidas duas estratgias que podem ser usadas pelos
coobjectos. Na primeira estratgia, cada rplica mantm uma matriz m, em que m[i, j] =m
i
j
signica que
se sabe que o servidor i conhece todas as operaes submetidas em j com nmero de sequncia menor ou
igual a m
i
j
. Na segunda estratgia, mantm-se um vector m, em que m[i] = m
i
signica que se sabe que
o servidor i conhece todas as operaes submetidas em todos os servidores com nmero de sequncia
igual ou inferior a m
i
. Esta segunda aproximao, proposta em [57], permite reduzir o espao necessrio
em [125] discute-se a utilizao desta ideia e a importncia da actualizao local do valor de l[i] para
que o valor de a possa evoluir rapidamente.
Ainformao sobre as operaes conhecidas nos outros servidores usada para remover as operaes
no necessrias. Assim, uma operao que seja conhecida em todos os outros servidores e j tenha sido
executada denitivamente pode ser removida.
A.2.2 Protocolo de propagao epidmica bilateral
O protocolo de propagao epidmica bilateral construdo com base nas seguintes quatro operaes
executadas relativamente a coobjectos do volume, com id o identicador do coobjecto a sincronizar e a
a informao sobre as operaes que se sabe serem conhecidas noutros servidores (usando qualquer uma
das estratgias descritas anteriormente):
(asksync, id, l, a) Pede o envio das operaes no conhecidas localmente, i.e., no reectidas no sumrio
l.
Ao receber esta operao, o servidor pode actualizar a informao sobre as operaes conhecidas
nos outros servidores.
Em resposta a esta operao deve ser emitida a operao (sync, . . .), (askstate, . . .) ou
(removed, . . .).
(sync, id, l, a, l
0
, ops) Envia o conjunto de operaes conhecidas localmente, ops, com sumrio l, e que
no esto reectidas no sumrio l
0
.
Ao receber esta operao, o servidor entrega as operaes recebidas ao coobjecto e actualiza o
sumrio das operaes conhecidas (com base no sumrio do parceiro, l, e no sumrio, l
0
, usado
para gerar ops). O servidor actualiza tambm a informao sobre as operaes conhecidas noutros
servidores.
Em resposta a esta operao deve ser emitida a operao (sync, . . .), (askstate, . . .) ou
(removed, . . .).
(askstate, id) Pede o envio do estado de um coobjecto (usado para propagar novos coobjectos).
Em resposta a esta operao deve ser emitida a operao (newstate, . . .).
(removed, id) Indica que o servidor obteve informao suciente para remover denitivamente o coob-
jecto id.
O servidor que recebe esta operao remove igualmente os recursos relativos ao coobjecto.
(newstate, id, o) Envia o estado de um coobjecto.
Ao receber esta operao, o servidor cria a cpia local do coobjecto, caso ela ainda no exista.
O estado de um coobjecto transmitido entre servidores inclui os atributos do sistema e uma sequn-
cia opaca de bytes obtida atravs dum mtodo denido na interface do coobjecto. Os atributos do
sistema especicam a fbrica do coobjecto esta fbrica usada para criar uma cpia do coob-
jecto a partir da sequncia de bytes recebida.
Nas guras A.1 e A.2 apresentam-se, de forma simplicada, as funes usadas no protocolo de sin-
cronizao. O protocolo consiste numa sequncia de passos executados assincronamente em cada um
dos passos um servidor processa as mensagens recebidas (usando a funo receive) e envia mensagens
para o seu parceiro (usando a funo send). A sequncia de mensagens enviadas pode ser propagada
conjuntamente usando qualquer transporte, sncrono ou assncrono.
O protocolo iniciado executando a funo initBiEpidemic, em que o servidor i pede que o servidor
j lhe envie, para todos os coobjectos a sincronizar, as operaes desconhecidas em i (usando a opera-
o (asksync, . . .)). Os passos seguintes do protocolo, executados alternadamente pelos servidores j e
i, consistem na execuo da funo stepBiEpidemic. Nesta funo, um servidor processa as operaes
submetidas pelo parceiro, como se explicou anteriormente (i.e., enviando e/ou recebendo operaes ou
pedindo/recebendo o estado de um novo coobjecto). Adicionalmente, o servidor pode submeter ope-
raes relativas a coobjectos no referenciados pelo parceiro. No incio de cada passo do protocolo, o
Variveis globais para um dado volume vol
U todos os coobjectos
Del identificadores dos coobjectos removidos
view_id identificador da vista actualmente instalada no servidor
srv identificador do servidor na vista instalada
memb coobjecto de filiao
Variveis denidas para um coobjecto o
o.id identificador do coobjecto no volume Id_local
o.l sumrio das operaes conhecidas em o
o.a informao sobre operaes conhecidas noutro servidores
o.ops conjunto de operaes conhecidas em o
Variveis usadas para identicar uma operao op
op.srv identificador do servidor
op.nseq nmero de sequncia da operao
Variveis usadas durante o protocolo
lastStep define se se est no ltimo passo do protocolo
Funes auxiliares
function exists( id): boolean
(1) return {o U : o.id = id} = / 0
function removed( id): boolean
(1) return {id0 Del : id0 = id} = / 0
function getCoobject( id): coobject
(1) return o U : o.id = id
function unknowOps( o, l): set
(1) return {op o.ops : op.nseq > l[op.srv]}
function unknowMembOps( l): set
(1) return {op memb.ops : op.nseq > l[op.srv]
op.srv no representado em l}
procedure send0( msg)
(1) if NOT lastStep then send msg end if
procedure updateLogged(o,l_0,l)
(1) n, o.l[n] l_0[n] o.l[n] := max(o.l[n], l[n])
procedure updateClock( o)
(1) o.l[srv] := max{o.l[n] : n}
procedure updateAck( o, a) // Golding
(1) o.a[srv] := min{o.l[n] : n}
(2) o.a[n] := max(o.a[n], a[n]), n, n = srv
procedure updateAck( o, a) // Matriz
(1) o.a[srv][n] := o.l[n] : n
(2) o.a[m][n] := max(o.a[m][n], a[m][n]), n, m, m = srv
Figura A.1: Funes bsicas e informao usada no protocolo de sincronizao bilateral (simplicado).
Funes do protocolo
procedure syncViewSend(view_peer)
(1) send (sync view,view_id,
unknownMembOps(view_peer))
procedure syncViewReceive()
(1) receive (sync view,view_peer,ops)
(2) memb.ops := memb_ops ops
(no protocolo local de mudana de vista)
(3) if view_id = view_peer then
(4) send (sync view,view_id,
unknownMembOps(view_peer))
(5) end if
procedure initBiEpidemic( Ob js)
(1) send (view_id)
(2) nStep := 1; full := Ob js =U
(3) send (nStep,full)
(4) for o Ob js do
(5) updateClock(o)
(6) send (ask sync,o.id,o.l,o.a)
(7) end for
(8) send (end)
procedure stepBiEpidemic()
(1) receive (view_peer)
(2) if view_id = view_peer then
(3) syncViewSend(view_peer); return;
(4) end if
(5) receive (nStep,full)
(6) lastStep := lastStep(nStep)
(7) send0 (view_id)
(8) send0 (nStep+1,full)
(9) Ob js = / 0
(10) forever do
(11) receive msg
(12) if msg.type = end then break end if
(13) processOne( msg)
(14) Ob js := Ob js {msg.id}
(15) end forever
(16) if full AND NOT lastStep then
(17) for o U : o.id / Ob js do
(18) send (ask sync,o.id,o.l,o.a)
(19) end for
(20) end if
(21) send0 (end)
procedure processOne( msg)
(1) case msg of
(2) (ask sync,id,l,a):
(3) if exists(id) then
(4) o = getCoobject(id)
(5) updateClock( o); updateAck( o, a)
(6) send0 (sync,id,o.l,o.a,unknownOps(o,l))
(7) else if removed(id) then
(8) send0 (removed,id)
(9) else
(10) send0 (ask state,id)
(11) end if
(12) (sync,id,l,a,l_0,ops):
(15) o.ops := o.ops ops
(16) updateLogged(o,l_0,l);updateClock(o);
updateAck(o,a)
(17) send0 (sync,id,o.l,o.a,l,unknownOps(o,l))
(18) else
(19) send0 (ask state,id)
(20) end if
(21) (removed,id):
(22) U := U \ {getCoob ject(id)}
(23) Del := Del {id}
(24) (ask state,id):
(27) send0 (new state,id,o)
(28) else
(29) // do nothing
(30) end if
(31) (new state,id,o):
(33) // error: do nothing
(34) else
(35) U := U {o}
(36) end if
Figura A.2: Funes do protocolo de sincronizao bilateral (simplicado).
i e j conhecem o coobjecto o
(1) i
(asksync,...)
j
(2) j
(sync,...)
i
i conhece todas as operaes conhecidas em j
(3) i
(sync,...)
j
j conhece todas as operaes conhecidas em
i
i conhece o coobjecto o e j no conhece
(1) i
(asksync,...)
j
(2) j
(askstate,...)
i
(3) i
(newstate,...)
j
j obtm o estado de o conhecido em i
j conhece o coobjecto o e i no conhece
(1) i
noop
j
(2) j
(asksync,...)
i
(3) i
(askstate,...)
j
(3) j
(newstate,...)
j
i obtm o estado de o conhecido em j
Figura A.3: Descrio da sincronizao de um coobjecto usando o protocolo de sincronizao bilateral.
servidor que recebe as mensagens verica se se encontra na mesma vista do servidor que enviou as men-
sagens (linhas 2-4 da funo stepBiEpidemic). Caso se encontrem em vistas diferentes, as mensagens
recebidas so ignoradas e os servidores iniciam um protocolo de sincronizao das vistas, enviando para
o outro servidor todas as operaes relativas ao coobjecto de liao desconhecidas pelo outro servidor.
Na gura A.3 apresentam-se as diferentes possibilidades de sincronizao de um coobjecto, depen-
dendo de o coobjecto ser j conhecido nos servidores quando o protocolo iniciado. Assim, verica-se
que o protocolo de sincronizao se pode concluir ao m da quarta interaco, i.e., quando o servidor
que iniciou o protocolo recebe uma resposta pela segunda vez nesse momento, cada um dos servido-
res recebeu as operaes conhecidas pelo outro servidor no momento em que iniciou a participao no
protocolo. No entanto, como o protocolo pode ser estabelecido usando meios de comunicao assncro-
nos, a latncia da comunicao pode aconselhar a que o protocolo continue por mais alguns passos. No
cdigo apresentado na gura A.2 esta deciso deve ser denida na funo lastStep. No ltimo passo do
protocolo, o servidor limita-se a processar as operaes recebidas do parceiro sem lhes responder.
O protocolo implementado no sistema DOORS apresenta algumas diferenas de pormenor em rela-
o ao cdigo das guras A.1 e A.2. Primeiro, ao conjunto de coobjectos a sincronizar, Objs, adicio-
nado o conjunto de coobjectos necessrios para os instanciar (i.e., seja o
code
i
o coobjecto que contm o
cdigo para instanciar o coobjecto o
i
, tem-se Objs Objs {o
code
i
: o
i
Objs}). Adicionalmente, os
coobjectos que contm cdigo para instanciar outros coobjectos so processados antes desses coobjectos
(i.e., o
code
i
processado antes de o
i
) desta forma garante-se que um servidor contm sempre o cdigo
necessrio a processar as operaes relativas aos coobjectos.
A segunda diferena consiste numa optimizao para omitir o envio de informao que se sabe que o
parceiro conhece. Assim, um servidor omite sempre o envio de operaes (sync, . . .) desde que as seguin-
tes condies se veriquem: (1) no existem operaes a enviar; (2) o sumrio das operaes conhecidas
pelos dois parceiros igual
8
o sumrio das operaes conhecidas no parceiro o recebido durante o
8
Esta condio no idntica anterior porque possvel sumrios diferentes reectirem o mesmo conjunto de operaes
por exemplo, se l[i] = n e l[i] = n+1 reectem o mesmo conjunto de operaes se no existir (no presente nem no futuro)
nenhuma operao submetida em i com nmero de sequncia n+1.
processo de sincronizao numa operao (asksync, . . .) ou (sync, . . .) ou obtido a partir da informa-
o sobre as operaes conhecidas noutros servidores; (3) a informao sobre as operaes conhecidas
noutros servidores igual quando a informao do parceiro no foi obtida no decurso do processo de
sincronizao, considera-se que a informao nos dois servidores igual, se pela informao conhecida
localmente se souber que todos os servidores conhecem todas as operaes conhecidas localmente. Um
servidor a efectuar uma sincronizao completa omite igualmente as operaes (asksync, . . .), se as duas
ltimas condies enunciadas anteriormente se vericarem (caso o parceiro conhea novas operaes,
ele enviar a operao (asksync, . . .) relativa a esse coobjecto). Esta optimizao permite que durante as
sesses de sincronizao no se troque informao relativa aos coobjectos estveis, i.e., aos coobjectos
cujas ltimas modicaes j se encontram disseminadas.
A terceira diferena consiste na omisso dos pormenores relativos ao mecanismo de dissemina-
o apresentado anteriormente. Assim, quando se conclui um processo de disseminao completo
(i.e, f ull verdadeiro), o servidor j, submete para cada pedido de disseminao pendente a operao
disseminated(uid, j, v
i
), como se tinha referido. Os valores de v
i
a serem usados so enviados por i a j
no incio do protocolo de sincronizao e mantidos por i at ao m do protocolo.
Finalmente, omitiram-se os detalhes relativos ao restauro de coobjectos.
A.2.3 Protocolo de propagao epidmica unilateral
No protocolo de propagao epidmica unilateral, um servidor, i, envia para outro servidor, j, a infor-
mao que permite a j sincronizar o estado de j com o estado de i (i.e., o servidor j deve car a conhecer
todas as operaes conhecidas em i). Na gura A.4 apresentam-se as funes usadas no protocolo. O
servidor i executa a funo uniEpidemic para enviar as operaes que pensa serem desconhecidas em
j. O servidor j executa a funo stepBiEpidemic usada no protocolo bilateral, mas no responde ao
servidor i. Um aspecto merece ateno neste protocolo: a funo unknownObj usada para estimar se o
servidor a que se destina a comunicao conhece o coobjecto que se est a considerar (caso no conhea
necessrio enviar o estado do coobjecto em vez das operaes para sincronizar o estado). A funo
apresentada na gura A.4 muito simples e poderia ser melhorada com o conhecimento sobre o envio
do estado dos novos coobjectos em anteriores sesses de sincronizao unilateral.
A.2.4 Sincronizao epidmica durante as mudanas na liao
O mecanismo de entrada e sada do grupo de replicadores exige que o servidor que entra ou sai do grupo
de replicadores comunique apenas com outro servidor. Enquanto as operaes de insero/remoo de
elementos no grupo de replicadores no so propagadas para todos os replicadores do volume (durante as
sesses de propagao epidmica), os servidores vo ter uma viso incompleta ou incorrecta dos actuais
Funes auxiliares
// Devolve um vector das operaes que se sabe serem conhecidas no servidor to_srv
function knownOps( o, to_srv): vector // Golding
(1) return l : l[i] := o.a[to_srv], i
function knownOps( o, to_srv): vector // Matriz
(1) return l : l[i] := o.a[to_srv][i], i
// Devolve verdadeiro se se pensa que o servidor to_srv desconhece o coobjecto o
function unknownObj( o, to_srv): boolean
(1) return o.l[to_srv] = 1
Funes do protocolo
procedure uniEpidemic( Ob js,to_srv)
(1) send (view_id)
(2) nStep := 1; full := Ob js =U
(3) send (nStep,full)
(4) for o Ob js do
(5) updateClock(o)
(6) if unknownObj( o, to_srv) then
(7) send (new state,o.id,o)
(8) else
(9) l := knownOps( o, to_srv)
(10) send (sync,o.id,o.l,o.a,l,unknownOps(o,l))
(11) end if
(12) end for
(13) send (end)
Figura A.4: Funes do protocolo de sincronizao unilateral (simplicado).
replicadores do volume. Assim, a poltica de sincronizao deve ter em ateno este facto de forma a
que as mudanas no grupo de replicadores sejam propagadas para todos os servidores.
Quando, devido informao local desactualizada, um servidor selecciona executar uma sesso de
sincronizao com um outro servidor que deixou de replicar o volume, a sesso de sincronizao
recusada. No entanto, os servidores que abandonam o grupo de replicadores mantm temporariamente
a informao sobre o conjunto de servidores que replicavam o volume no momento da sua remoo
esta informao devolvida aos servidores que tentam estabelecer sesses de sincronizao e poder ser
usada pela poltica de sincronizao para determinar o prximo servidor a ser contactado.
Em situaes extremas, quando existem vrias entradas e sadas no grupo de replicadores num curto
intervalo de tempo sem que as respectivas operaes possam ser propagadas entre os servidores, pos-
svel que existam dois servidores, i e j, que replicam um mesmo volume e que no conhecem nenhum
servidor activo que lhe permita conhecer o outro, i.e., (usando a b para representar que a sabe que b
pertence ao grupo de replicadores e activo(a) para representar que o servidor a no abandonou o grupo
de replicadores) s
0
, . . . , s
n
: i s
0
activo(s
0
) s
0
s
1
activo(s
1
) . . . s
n
j. Nesta situao, a
execuo de sesses de sincronizao apenas com o conjunto dos servidores que pertencem vista actual
poderia levar criao de subconjuntos isolados de replicadores que no comunicam entre si.
Para detectar esta situao, para cada volume, mantm-se a informao sobre o momento em que se
realizaram (directa ou transitivamente) as ltimas sesses de sincronizao com os outros servidores
esta informao transmitida e actualizada durante as sesses de sincronizao. O facto de um servidor
activo na vista instalada localmente no participar nas sesses de sincronizao durante um perodo
de tempo longo, considerando a frequncia esperada das sesses de sincronizao, pode indiciar que
o servidor foi removido usando como patrocinador um servidor que desconhecido (outra hiptese
tratar-se de um servidor desconectado temporariamente do sistema).
Um servidor, i, que detecte a situao anterior deve tentar estabelecer uma sesso de sincronizao
com o servidor, j, que no tem participado nas sesses de sincronizao. Se o servidor j responder, duas
hipteses so possveis. Primeiro, j ainda pertence ao grupo de replicadores neste caso a sesso de
sincronizao decorre normalmente. Segundo, j j no pertence ao grupo de replicadores e devolve a
lista dos servidores que pertenciam ao grupo de replicadores no momento da sua remoo. No caso de
existir algum elemento que no faa parte da vista instalada localmente, i deve tentar estabelecer uma
sesso de sincronizao com esse servidor. Caso todos os elementos da lista devolvida por j pertenam
ao conjunto de replicadores conhecidos em i, i deve aguardar que a informao da remoo de j do
grupo de replicadores seja propagada at si (ou pode, alternativamente, estabelecer uma sesso de sin-
cronizao com o patrocinador da remoo de j). Se o servidor j no responder, o servidor i pode usar o
mecanismo de descoberta dos servidores que replicam um dado volume (descrito na seco 6.2.3) para
tentar encontrar novos servidores que pertenam ao grupo de replicadores.
A.2.5 Disseminao de novas operaes
Alm do mecanismo bsico de sincronizao usando sesses epidmicas, cada servidor propaga os even-
tos submetidos localmente usando um canal de disseminao no vel (descrito na seco 6.2.3). O
evento propagado tem a seguinte forma newop(view
id
, id, op, nseq
old
), com view
id
o identicador da
vista no servidor que submete o evento, id o identicador do coobjecto no qual a operao foi sub-
metida, op a sequncia de operaes que o servidor est a disseminar (op.srv e op.nseq identicam a
operao), e nseq
old
o nmero de sequncia da operao que tinha sido identicada anteriormente em
op.srv.
Um servidor, ao receber um evento newop(view
id
, id, op, nseq
old
), verica se o identicador da vista
igual ao identicador da vista instalada localmente e se o coobjecto referido conhecido localmente.
Em caso armativo, a operao op entregue ao coobjecto com identicador id e o sumrio das opera-
es conhecidas localmente actualizado se se vericar que no existe nenhuma outra operao iden-
ticada nesse servidor que no seja conhecida, i.e., seja o o coobjecto com identicador id, tem-se que
o.l[op.srv] nseq
old
o.l[op.srv] op.nseq.
Apndice B
Mobisnap
B.1 Transaces mveis:linguagem
As transaces mveis so especicadas num subconjunto da linguagem PL/SQL [112]. As (poucas)
modicaes introduzidas esto ligadas com as especicidades das transaces mveis e com limitaes
do prottipo do sistema Mobisnap. De seguida, apresentam-se brevemente os elementos que podem ser
usados na denio de uma transaco mvel:
Tipos Esto disponveis os seguintes tipos escalares pr-denidos no PL/SQL: carcter e cadeia de
caracteres, nmero inteiro e real com preciso varivel, data, booleano.
Constantes e variveis possvel denir constantes e variveis dos tipos pr-denidos.
Instruo de atribuio Atribui o valor de uma expresso a uma varivel.
Bloco begin [exception ] end Dene uma sequncia de instrues, com tratamento opcional de
excepes. Uma excepo pode ser criada (lanada) usando a instruo raise.
Instruo if Permite denir cdigo executado condicionalmente (esto denidas as seguintes variantes:
if then, if then else, if then elseif ).
Instruo select into Atribui o resultado de uma interrogao base de dados a uma varivel. Ao
contrrio do PL/SQL normalizado, esta instruo pode ser usada para obter o primeiro resultado
de uma pergunta que tenha mltiplas respostas.
Instrues update, insert e delete Modica o estado da base de dados.
Funo notify Envia uma mensagem a um utilizador permite especicar o destinatrio da mensagem,
o transporte a utilizar, e o contedo da mensagem a transmitir.
221
222 APNDICE B. MOBISNAP
Funo newid Gera um identicador nico que pode ser usado como identicador de um registo. A
execuo de cada invocao desta funo numa transaco mvel devolve o mesmo valor em todas
as suas execues (no cliente e no servidor).
Instrues commit e rollback A instruo commit conclui a execuo da transaco mvel com sucesso
(e torna persistente as alteraes efectuadas base de dados). A instruo rollback aborta a execu-
o da transaco mvel (e desfaz as alteraes efectuadas base de dados). Ao contrrio do que
usual, a execuo destas instrues permite especicar uma sequncia de valores (resultados) a
devolver aplicao.
Blocos on commit e on rollback Denem cdigo a ser executado aps a transaco concluir a sua exe-
cuo (de forma semelhante ao cdigo de tratamento de excepes). Este cdigo no pode incluir
as instrues commit e rollback.
Uma transaco mvel denida como um bloco annimo com a seguinte estrutura.
[ declare
-- Seco de declaraes
-- definio de tipos, variveis e constantes ]
begin
-- Seco executvel
-- instrues do programa
[ exception
when ... then
-- bloco a executar para tratamento de uma excepo ]
[ on commit
-- bloco a executar em caso de execuo com sucesso ]
[ on rollback
-- bloco a executar em caso de execuo falhada ]
end;
Por omisso, a execuo de uma transaco mvel termina com sucesso se o caminho de execuo
alcanar o m das instrues do programa (excluindo os blocos on commit/rollback), i.e., se no terminar
numa instruo commit ou rollback. Neste caso, o bloco on commit ser executado. Caso o processa-
mento de uma transaco termine com a criao de uma excepo no tratada, a transaco mvel
abortada e o bloco on rollback executado (caso exista).
Em relao ao PL/SQL, as instrues disponveis para denir uma transaco mvel apresentam al-
gumas limitaes. Entre estas limitaes incluem-se a denio de tipos compostos (record) e ancorados,
a denio de ciclos, o acesso base de dados usando cursores, e a denio de funes e procedimentos
auxiliares que possam ser usados pelas transaces mveis. Estas limitaes foram introduzidas apenas
para simplicar a criao do prottipo do sistema Mobisnap, no representando nenhuma limitao do
modelo do sistema apresentado nesta dissertao.
Bibliograa
[1] S. Agarwal, D. Starobinski, e A. Trachtenberg. On the scalability of data synchronization protocols
for pdas and mobile devices. IEEE Network (Special Issue on Scalability in Communication
Networks), 16(4):2228, 2002.
[2] D. Agrawal, A. El Abbadi, e R. C. Steinke. Epidemic algorithms in replicated databases (exten-
ded abstract). Em Proceedings of the sixteenth ACM SIGACT-SIGMOD-SIGART symposium on
Principles of database systems, pgs. 161172. ACM Press, 1997.
[3] Marcos Kawazoe Aguilera, Wei Chen, e Sam Toueg. Failure detection and consensus in the
crash-recovery model. Distributed Computing, 13(2):99125, 2000.
[4] A. V. Aho, Y. Sagiv, e J. D. Ullman. Efcient optimization of a class of relational expressions.
ACM Transactions on Database Systems (TODS), 4(4):435454, 1979.
[5] Paulo Srgio Almeida, Carlos Baquero, e Victor Fonte. Version stamps - decentralized ver-
sion vectors. Em Proc. of the 22
nd
International Conference on Distributed Computing Systems
(ICDCS02), pgs. 544. IEEE Computer Society, Julho de 2002.
[6] Rafael Alonso, Daniel Barbara, e Hector Garcia-Molina. Data caching issues in an information
retrieval system. ACM Transactions on Database Systems (TODS), 15(3):359384, 1990.
[7] Rafael Alonso e Henry F. Korth. Database system issues in nomadic computing. Em Proceedings
of the 1993 ACM SIGMOD international conference on Management of data, pgs. 388392.
ACM Press, 1993.
[8] Peter A. Alsberg e John D. Day. A principle for resilient sharing of distributed resources. Em
Proceedings of the 2nd international conference on Software engineering, pgs. 562570. IEEE
Computer Society Press, 1976.
[9] Yair Amir e Avishai Wool. Evaluating quorum systems over the internet. Em Proceedings of the
Twenty-Sixth Annual International Symposium on Fault-Tolerant Computing (FTCS 96), pgs.
2635, Junho de 1996.
223
224 BIBLIOGRAFIA
[10] Glenn Ammons, Rastislav Bodk, e James R. Larus. Mining specications. Em Proc. 29
th
ACM
Symp. on Principles of programming languages, 2002.
[11] Ronald M. Baecker, editor. Readings in Groupware and Computer-Supported Cooperative Work:
Assisting Human-Human Collaboration. Morgan Kaufmann Publishers, 1993.
[12] Arno Bakker, Maarten van Steen, e Andrew S. Tanenbaum. From remote objects to physically
distributed objects. Em Proceedings of the 7
th
IEEE Workshop on Future Trends of Distributed
Computing Systems, pgs. 4752. IEEE Computer Society Press, Dezembro de 1999.
[13] Daniel Barbar. Mobile computing and databases - a survey. Knowledge and Data Engineering,
11(1):108117, 1999.
[14] Daniel Barbar e Tomasz Imielinski. Sleepers and workaholics: caching strategies in mobile envi-
ronments. Em Proceedings of the 1994 ACM SIGMOD international conference on Management
of data, pgs. 112. ACM Press, 1994.
[15] Michael Ben-Or. Another advantage of free choice (extended abstract): Completely asynchronous
agreement protocols. Em Proceedings of the second annual ACM symposium on Principles of
distributed computing, pgs. 2730, 1983.
[16] R. Bentley, W. Appelt, U. Busbach, E. Hinrichs, D. Kerr, K. Sikkel, J. Trevor, e G. Woetzel. Basic
support for cooperative work on the world wide web. International Journal of Human Computer
Studies: Special issue on Novel Applications of the WWW, 46(6):827856, Spring de 1997.
[17] P. A. Bernstein, V. Hadzilacos, e N. Goodman. Concurrency Control and Recovery in Database
Systems. Addison Wesley, Reading, MA, 1987.
[18] Kenneth P. Birman. The process group approach to reliable distributed computing. Communica-
tions of the ACM, 36(12):3753, 1993.
[19] Bluetooth. http://www.bluetooth.com.
[20] Georges Brun-Cottan e Mesaac Makpangou. Adaptable replicated objects in distributed environ-
ments. Rapport de Recherche 2593, Institut National de la Recherche en Informatique et Auto-
matique (INRIA), Rocquencourt (France), Maio de 1995. http://www-sor.inria.fr/publi/
RCMFGCCOSDS_rr2593.
[21] Diego Calvanese, Giuseppe De Giacomo, e Maurizio Lenzerini. On the decidability of query con-
tainment under constraints. Em Proceedings of the seventeenth ACM SIGACT-SIGMOD-SIGART
symposium on Principles of database systems, pgs. 149158. ACM Press, 1998.
BIBLIOGRAFIA 225
[22] Michael J. Carey, David J. DeWitt, e Jeffrey F. Naughton. The OO7 benchmark. SIGMOD Record
(ACM Special Interest Group on Management of Data), 22(2):1221, 1993.
[23] Miguel Castro, Atul Adya, Barbara Liskov, e Andrew C. Meyers. Hac: hybrid adaptive caching
for distributed storage systems. Em Proceedings of the sixteenth ACM Symposium on Operating
Systems Principles, pgs. 102115. ACM Press, 1997.
[24] Per Cederqvist, Roland Pesch, et al. Version management with CVS, date unknown. http:
//www.cvshome.org/docs/manual.
[25] U. Cetintemel, B. zden, M. Franklin, e A. Silberschatz. Design and evaluation of redistribution
strategies for wide-area commodity distribution. Em Proc. of the 21
st
International Conference
on Distributed Computing Systems, pgs. 154164. IEEE Press, Abril de 2001.
[26] Bharat Chandra, Mike Dahlin, Lei Gao, e Amol Nayate. End-to-end wan service availability,
Maro de 2001.
[27] Jia-Bing R. Cheng e A. R. Hurson. Effective clustering of complex objects in object-oriented
databases. Em Proceedings of the 1991 ACM SIGMOD international conference on Management
of data, pgs. 2231. ACM Press, 1991.
[28] Gregory Chockler, Dahlia Malkhi, e Michael K. Reiter. Backoff protocols for distributed mutual
exclusion and ordering. Em Proceedings of the 21
st
International Conference on Distributed
Computing Systems, pgs. 1120. IEEE Press, Abril de 2001.
[29] Ian Clarke, Oskar Sandberg, Brandon Wiley, e Theodore W. Hong. Freenet: A distributed anony-
mous information storage and retrieval system. Em Proceedings of the ICSI Workshop on Design
Issues in Anonymity and Unobservability, pgs. 311320, Junho de 2000.
[30] Brian A. Coan, Brian M. Oki, e Elliot K. Kolodner. Limitations on database availability when
networks partition. Em Proceedings of the fth annual ACM symposium on Principles of distribu-
ted computing, pgs. 187194. ACM Press, 1986.
[31] Cryptix. Cryptix jce implementation. http://www.cryptix.org/.
[32] Miguel Cunha. Prottipo de teste do sistema mobisnap. Relatrio do projecto nal de curso,
Departamento de Informtica, FCT, Universidade de Lisboa, Fevereiro de 2001.
[33] Miguel Cunha, Nuno Preguia, Jos Legatheaux Martins, Henrique Joo Domingos, Fransisco
Moura, e Carlos Baquero. Mobisnap: Um sistema de bases de dados para ambientes mveis. Em
Nas Actas da Conferncia de Redes de Computadores 2001 (CRC2001), Novembro de 2001.
226 BIBLIOGRAFIA
[34] Grupo DAgora. Projecto dagora. http://asc.di.fct.unl.pt/dagora.
[35] Shaul Dar, Michael J. Franklin, Bjrn Jnsson, Divesh Srivastava, e Michael Tan. Semantic data
caching and replacement. Em Proc. VLDB96, pgs. 330341. Morgan Kaufmann, Setembro de
1996.
[36] Grupo DataBricks. Projecto databricks. http://asc.di.fct.unl.pt/databricks.
[37] Susan B. Davidson, Hector Garcia-Molina, e Dale Skeen. Consistency in a partitioned network: a
survey. ACM Computing Surveys (CSUR), 17(3):341370, 1985.
[38] Alan Demers, Dan Greene, Carl Hauser, Wes Irish, e John Larson. Epidemic algorithms for repli-
cated database maintenance. Em Proceedings of the sixth annual ACM Symposium on Principles
of distributed computing, pgs. 112. ACM Press, 1987.
[39] Henrique Joo L. Domingos. Suporte de Sesses de Trabalho Cooperativo Multi-Sncrono em
Ambientes de Grande Escala - Estruturao dos Suportes de Comunicao, Colaborao e Coor-
denao. Tese de doutoramento, Dep. Informtica, FCT, Universidade Nova de Lisboa, Fevereiro
de 2000.
[40] Henrique Joo L. Domingos, Nuno M. Preguia, e J. Legatheaux Martins. Coordination and
awareness support for adaptive cscw sessions. CLEI Journal - Journal of Latino American CYTED
RITOS Network, Special Issue of Collaborative Systems, Abril de 1999.
[41] Paul Dourish. The parting of the ways: Divergence, data management and collaborative work. Em
Proceedings of the European Conference on Computer-Supported Cooperative Work ECSCW95,
pgs. 213222. ACM Press, Setembro de 1995.
[42] Paul Dourish. Using metalevel techniques in a exible toolkit for cscw applications. ACM Tran-
sactions on Computer-Human Interaction (TOCHI), 5(2):109155, 1998.
[43] Paul Dourish e Victoria Bellotti. Awareness and coordination in shared workspaces. Em Proce-
edings of the 1992 ACM conference on Computer-supported cooperative work, pgs. 107114.
ACM Press, 1992.
[44] Paul Dourish, W. Keith Edwards, Anthony LaMarca, John Lamping, Karin Petersen, Michael
Salisbury, Douglas B. Terry, e James Thornton. Extending document management systems with
user-specic active properties. ACM Transactions on Information Systems (TOIS), 18(2):140170,
2000.
BIBLIOGRAFIA 227
[45] Srgio Duarte, J. Legatheaux Martins, Henrique J. Domingos, e Nuno Preguia. Deeds - a distri-
buted and extensible event dissemination service. Em Proceedings of the 4
th
European Research
Seminar on Advances in Distributed Systems (ERSADS), Maio de 2001.
[46] C. A. Ellis e S. J. Gibbs. Concurrency control in groupware systems. Em Proceedings of the 1989
ACM SIGMOD international conference on Management of data, pgs. 399407. ACM Press,
1989.
[47] Clarence A. Ellis, Simon J. Gibbs, e Gail Rein. Groupware: some issues and experiences. Com-
munications of the ACM, 34(1):3958, 1991.
[48] Dawson Engler, David Yu Chen, e Andy Chou. Bugs as inconsistent behavior: A general approach
to inferring errors in systems code. Em Proc. 18
th
Symp. on Op. Sys. Principles, pgs. 5772,
2001.
[49] H.R. Nielson F. Nielson e C. Hankin. Principles of Program Analysis. Springer-Verlag, 1999.
[50] Alan Fekete, David Gupta, Victor Luchangco, Nancy Lynch, e Alex Shvartsman. Eventually-se-
rializable data services. Em Proceedings of the fteenth annual ACM symposium on Principles of
distributed computing, pgs. 300309. ACM Press, 1996.
[51] Paulo Ferreira, Marc Shapiro, Xavier Blondel, Olivier Fambon, Joo Garcia, Sytse Kloosterman,
Nicolas Richer, Marcus Roberts, Fadi Sandakly, George Coulouris, Jean Dollimore, Paulo Gue-
desand Daniel Hagimont, e Sacha Krakowiak. Design, implementation, and use of a persistent
distributed store. Em Advances in Distributed Systems, volume 1752 de Lecture Notes in Compu-
ter Science, pgs. 427452. Springer, 1999.
[52] Michael J. Fischer, Nancy A. Lynch, e Michael S. Paterson. Impossibility of distributed consensus
with one faulty process. Journal of the ACM (JACM), 32(2):374382, 1985.
[53] T. Frank e M. Vornberger. Sales forecasting using neural networks. Em Proc. ICNN97, volume 4,
pgs. 21252128, 1997.
[54] Michael J. Franklin, Michael J. Carey, e Miron Livny. Local disk caching for client-server database
systems. Em Proceedings of the 19
th
International Conference on Very Large Data Bases. Morgan
Kaufmann, Agosto de 1993.
[55] Carsten A. Gerlhof, Alfons Kemper, e Guido Moerkotte. On the cost of monitoring and reorgani-
zation of object bases for clustering. ACM SIGMOD Record, 25(3):2227, 1996.
228 BIBLIOGRAFIA
[56] David K. Gifford. Weighted voting for replicated data. Em Proceedings of the seventh symposium
on Operating systems principles, pgs. 150162, 1979.
[57] Richard A. Golding. Weak-Consistency Group Communication and Membership. PhD thesis,
University of California, Santa Cruz, Dezembro de 1992.
[58] C. Gray e D. Cheriton. Leases: an efcient fault-tolerant mechanism for distributed le cache con-
sistency. Em Proc. of the 12
th
ACM Symposium on Operating systems principles, pgs. 202210.
ACM Press, 1989.
[59] Jim Gray, Pat Helland, Patrick ONeil, e Dennis Shasha. The dangers of replication and a solution.
Em Proceedings of the 1996 ACM SIGMOD International Conference on Management of Data,
pgs. 173182. ACM Press, 1996.
[60] Jim Gray e Andreas Reuter. Transction Processing: Concepts and Techniques. Morgan Kaufmann
Publishers, 1993.
[61] Saul Greenberg e David Marwood. Real time groupware as a distributed system: concurrency
control and its effect on the interface. Em Proceedings of the 1994 ACM conference on Computer
supported cooperative work, pgs. 207217. ACM Press, 1994.
[62] Saul Greenberg e Mark Roseman. Using a room metaphor to ease transitions in groupware. Tech-
nical Report 98/611/02, Department of Computer Science, University of Calgary, Alberta, Canada,
Janeiro de 1998.
[63] Irene Greif e Sunil Sarin. Data sharing in group work. ACM Transactions on Information Systems
(TOIS), 5(2):187211, 1987.
[64] Irene Greif, Robert Seliger, e William E. Weihl. Atomic data abstractions in a distributed col-
laborative editing system. Em Proceedings of the 13th ACM SIGACT-SIGPLAN symposium on
Principles of programming languages, pgs. 160172. ACM Press, 1986.
[65] Carl Gutwin e Saul Greenberg. Effects of awareness support on groupware usability. Em Proce-
edings of the SIGCHI conference on Human factors in computing systems, pgs. 511518. ACM
Press/Addison-Wesley Publishing Co., 1998.
[66] Richard G. Guy, John S. Heidemann, Wai Mak, Thomas W. Page Jr., Gerald J. Popek, e Dieter
Rothmeier. Implementation of the cus replicated le system. Em Proceedings of the Summer
1990 USENIX Conference, pgs. 6371, Junho de 1990.
BIBLIOGRAFIA 229
[67] Jrg M. Haake e Brian Wilson. Supporting collaborative writing of hyperdocuments in sepia.
Em Proceedings of the 1992 ACM conference on Computer-supported cooperative work, pgs.
138146. ACM Press, 1992.
[68] D. Hagimont e D. Louvegnies. Javanaise: Distributed shared objects for internet cooperative appli-
cations. Em Proceedings of the IFIP International Conference on Distributed Systems Platforms
and Open Distributed Processing (Middleware98). Springer, Setembro de 1998.
[69] Seth Hallem, Benjamin Chelf, Yichen Xie, e Dawson Engler. A system and language for building
system-specic, static analyses. Em Proc. 2002 Conf. on Programming language Design and
Implementation, pgs. 6982. ACM Press, 2002.
[70] Joanne Holliday, R. Steinke, Divyakant Agrawal, e Amr El Abbadi. Epidemic algorithms for
replicated databases. IEEE Transactions on Knowledge and Data Engineering, 15(3), 2003.
[71] hsqldb group. hsqldb java database engine. http://hsqldb.sourceforge.net/.
[72] M. Hurn, A. Mostefaoui, e M. Raynal. Consensus in asynchronous systems where processes
can crash and recover. Em Proceedings of the 17
th
Symposium on Reliable Distributed Systems
(SRDS), pgs. 280286, Outubro de 1998.
[73] IEEE. Ieee 802.11. http://grouper.ieee.org/groups/802/11.
[74] ILOG. Ilog jsolver. http://www.ilog.com/products/jsolver/.
[75] Yannis E. Ioannidis e Raghu Ramakrishnan. Containment of conjunctive queries: beyond relations
as sets. ACM Transactions on Database Systems (TODS), 20(3):288324, 1995.
[76] ISO/IEC. Iso/iec 9075: Database language sql, international standard, 1992.
[77] Larry S. Jackson e Ed Grossman. Integration of synchronous and asynchronous collaboration
activities. ACM Computing Surveys (CSUR), 31(2es):12, 1999.
[78] Jin Jing, Abdelsalam Sumi Helal, e Ahmed Elmagarmid. Client-server computing in mobile
environments. ACM Computing Surveys (CSUR), 31(2):117157, 1999.
[79] A. D. Joseph, A. F. de Lespinasse, J. A. Tauber, D. K. Gifford, e M. F. Kaashoek. Rover: a toolkit
for mobile information access. Em Proceedings of the fteenth ACM symposium on Operating
systems principles, pgs. 156171. ACM Press, 1995.
[80] L. Kawell Jr., S. Beckhardt, T. Halvorsen, R. Ozme, e I.Greif. Replicated document management
in a group communication system. Em D. Marca e G. Bock, editores, Groupware: Software
230 BIBLIOGRAFIA
for Computer-Supported Cooperative Work, pgs. 226235. IEEE Computer Society Press, Los
Alamitos, CA, 1992.
[81] Alain Karsenty e Michel Beaudouin-Lafon. An algorithm for distributed groupware applications.
Em Proceedings of the 13th International Conference on Distributed Computing Systems, pgs.
195202. IEEE Computer Society Press, Maio de 1993.
[82] Peter J. Keleher. Decentralized replicated-object protocols. Em Proceedings of the eighteenth an-
nual ACM symposium on Principles of distributed computing, pgs. 143151. ACM Press, 1999.
[83] Bettina Kemme e Gustavo Alonso. A new approach to developing and implementing eager da-
tabase replication protocols. ACM Transactions on Database Systems (TODS), 25(3):333379,
2000.
[84] Anne-Marie Kermarrec, Laurent Massouli, e Ayalvadi J. Ganesh. Probabilistic reliable dis-
semination in large-scale systems. IEEE Transactions on Parallel and Distributed Systems,
4(3):248258, Maro de 2003.
[85] Anne-Marie Kermarrec, Antony Rowstron, Marc Shapiro, e Peter Druschel. The icecube appro-
ach to the reconciliation of divergent replicas. Em Proceedings of the twentieth annual ACM
symposium on Principles of distributed computing, pgs. 210218. ACM Press, 2001.
[86] Minkyong Kim, Landon P. Cox, e Brian D. Noble. Safety, visibility, and performance in a wide-a-
rea le system. EmProceedings of the First USENIX Conference on File and Storage Technologies
(FAST02), pgs. 131144. USENIX Association, Janeiro de 2002.
[87] James J. Kistler e M. Satyanarayanan. Disconnected operation in the coda le system. ACM
Transactions on Computer Systems (TOCS), 10(1):325, 1992.
[88] M. Koch. Design issues and model for a distributed multi-user editor. Computer Supported
Cooperative Work, 3(3-4):359378, 1995.
[89] Narayanan Krishnakumar e Arthur J. Bernstein. Bounded ignorance: a technique for incre-
asing concurrency in a replicated system. ACM Transactions on Database Systems (TODS),
19(4):586625, 1994.
[90] Narayanan Krishnakumar e Ravi Jain. Escrow techniques for mobile sales and inventory applica-
tions. Wireless Networks, 3(3):235246, 1997.
[91] Geoffrey H. Kuenning e Gerald J. Popek. Automated hoarding for mobile computers. Em Proc.
of the 16
th
ACM Symposium on Operating Systems Principles, pgs. 264275. ACM Press, 1997.
BIBLIOGRAFIA 231
[92] David Lacey, Neil D. Jones, Eric Van Wyk, e Carl Christian Frederiksen. Proving correctness of
compiler optimizations by temporal logic. Em Proc. 29
th
ACM Symp. on Principles of Program-
ming Languages, pgs. 283294. ACM Press, 2002.
[93] Rivka Ladin, Barbara Liskov, Liuba Shrira, e Sanjay Ghemawat. Providing high availability using
lazy replication. ACM Transactions on Computer Systems, 10(4):360391, 1992.
[94] Leslie Lamport. Time, clocks, and the ordering of events in a distributed system. Communications
of the ACM, 21(7):558565, 1978.
[95] Leslie Lamport. The part-time parliament. ACM Transactions on Computer Systems (TOCS),
16(2):133169, 1998.
[96] Yui-Wah Lee, Kwong-Sak Leung, e Mahadev Satyanarayanan. Operation-based update propaga-
tion in a mobile le system. Em Proceedings of the USENIX 1999 Annual Technical Conference,
Monterey, CA, USA, Jun de 1999.
[97] Mary D. P. Leland, Robert S. Fish, e Robert E. Kraut. Collaborative document production using
quilt. Em Proceedings of the 1988 ACM conference on Computer-supported cooperative work,
pgs. 206215. ACM Press, 1988.
[98] Sheng Feng Li, Quentin Stafford-Fraser, e Andy Hopper. Integrating synchronous and asynchro-
nous collaboration with virtual network computing. IEEE Internet Computing, 4(3):2633, 2000.
[99] Olivier Liechti. Awareness and the www: an overview. ACM SIGGROUP Bulletin, 21(3):312,
2000.
[100] B. Liskov, A. Adya, M. Castro, S. Ghemawat, R. Gruber, U. Maheshwari, A. C. Myers, M. Day, e
L. Shrira. Safe and efcient sharing of persistent objects in thor. Em Proceedings of the 1996 ACM
SIGMOD international conference on Management of data, pgs. 318329. ACM Press, 1996.
[101] Lotus. Lotus notes. http://www.lotus.com.
[102] Nancy Lynch. Distributed Algorithms. Morgan Kaufmann Publishers, 1996.
[103] Bruce M. Maggs, Friedhelm Meyer auf der Heide, Berthold Vocking, e Matthias Westermann.
Exploiting locality for data management in systems of limited bandwidth. Em IEEE Symposium
on Foundations of Computer Science, pgs. 284293, 1997.
[104] Microsoft. Microsoft access. http://www.microsoft.com/office/access/default.asp.
232 BIBLIOGRAFIA
[105] Pascal Molli, Hala Skaf-Molli, Grald Oster, e Sbastien Jourdain. Sams: Synchronous, asyn-
chronous, multi-synchronous environments. Em Proceedings of the 2002 ACM conference on
Computer supported cooperative work, 2002.
[106] Mortbay. Jetty:// web server & servlet container. http://jetty.mortbay.org/.
[107] Lily B. Mummert e M. Satyanarayanan. Large granularity cache coherence for intermittent con-
nectivity. Em Proceedings of the USENIX Summer Conference, pgs. 279289, Junho de 1994.
[108] Jonathan P. Munson e Prasun Dewan. Sync: A java framework for mobile collaborative applicati-
ons. IEEE Computer, 30(6):5966, Junho de 1997.
[109] Objectivity. Objectivity/db technical overview, 1999. http://www.objectivity.com.
[110] R. Oliveira, R. Guerraoui, e A. Schiper. Consensus in the crash-recover model. Technical Report
TR-97/239, EPFL, Computer Science Department, Agosto de 1997. http://lsewww.epfl.ch/
~schiper/papers/1997/tr-97-239.ps.
[111] Patrick E. ONeil. The escrow transactional method. ACM Transactions on Database Systems
(TODS), 11(4):405430, 1986.
[112] Oracle. Pl/sql users guide and reference - release 8.0, Junho de 1997.
[113] Oracle. Oracle8 enterprise edition, 1998.
[114] Oracle. Oracle8i advanced replication: An oracle technical white paper, Fevereiro de 1999.
[115] Oracle. Oracle8i lite replication guide - release 4.0, 1999.
[116] Franois Pacull, Alain Sandoz, e Andr Schiper. Duplex: a distributed collaborative editing en-
vironment in large scale. Em Proceedings of the 1994 ACM conference on Computer supported
cooperative work, pgs. 165173. ACM Press, 1994.
[117] Palm. Introduction to conduit development. http://www.palmos.com/dev/support/docs/
conduits/win/IntroToConduitsTOC.%html.
[118] Christopher R. Palmer e Gordon V. Cormack. Operation transforms for a distributed shared spre-
adsheet. Em Proceedings of the 1998 ACM conference on Computer supported cooperative work,
pgs. 6978. ACM Press, 1998.
[119] D. Scott Parker, Gerald Popek, Gerard Rudisin, Allen Stoughton, Bruce Walker, Evelyn Walton,
Johanna Chow, David Edwards, Stephen Kiser, e Charles Kline. Detection of mutual inconsistency
in distributed systems. IEEE Transactions on Software Engineering, SE-9(3):240247, 1983.
BIBLIOGRAFIA 233
[120] Vern E. Paxson. Measurements and Analysis of End-to-End Internet Dynamics. PhD thesis,
University of California, Berkeley, Abril de 1997.
[121] David Peleg e Avishai Wool. The availability of quorum systems. Information and Computation,
123(2):210223, 1995.
[122] Karin Petersen, Mike J. Spreitzer, Douglas B. Terry, Marvin M. Theimer, e Alan J. Demers. Fle-
xible update propagation for weakly consistent replication. Em Proceedings of the sixteenth ACM
symposium on Operating Systems Principles, pgs. 288301. ACM Press, 1997.
[123] Shirish Phatak e B. R. Badrinath. Multiversion reconciliation for mobile databases. Em Procee-
dings 15
th
International Conference on Data Engineering (ICDE), pgs. 582589. IEEE Compu-
ter Society, Maro de 1999.
[124] E. Pitoura e G. Samaras. Data Management for Mobile Computing, volume 10. Kluwer Academic
Publishers, 1998.
[125] Nuno Preguia. Repositrio de objectos de suporte ao trabalho cooperativo assncrono. Tese de
mestrado, Dep. Informtica, FCT, Universidade Nova de Lisboa, Outubro de 1997.
[126] Nuno Preguia, Carlos Baquero, Fransisco Moura, J. Legatheaux Martins, Rui Oliveira, Henrique
Domingos, J. Orlando Pereira, e Srgio Duarte. Mobile transaction management in mobisnap.
Em East-European Conference on Advances in Databases and Information Systems Held Jointly
with International Conference on Database Systems for Advanced Applications, ADBIS-DASFAA
2000, volume 1884 de Lecture Notes in Computer Science, pgs. 379386. Springer, 2000.
[127] Nuno Preguia e J. Legatheaux Martins. Revisiting hierarchical quorum systems. Em Proceedings
of the 21
st
International Conference on Distributed Computing Systems, pgs. 264274. IEEE
Press, Abril de 2001.
[128] Nuno Preguia, J. Legatheaux Martins, Miguel Cunha, e Henrique Domingos. Reservations for
conict-avoidance in a mobile database system. Em Proceedings of The First International Con-
ference on Mobile Systems, Applications, and Services (MobiSys 2003), pgs. 4356. Usenix As-
sociation, Maio de 2003.
[129] Nuno Preguia, J. Legatheaux Martins, e Henrique Domingos. Flexible data storage for mobile
collaborative applications. Em Proceedings of the Third European Research Seminar on Advances
in Distributed Systems, Abril de 1999.
234 BIBLIOGRAFIA
[130] Nuno Preguia, J. Legatheaux Martins, Henrique Domingos, e Srgio Duarte. Data management
support for asynchronous groupware. Em Proceedings of the 2000 ACM conference on Computer
supported cooperative work, pgs. 6978. ACM Press, 2000.
[131] Nuno Preguia, J. Legatheaux Martins, Henrique Domingos, e Srgio Duarte. Supporting dis-
connected operation in doors (position summary). Em Proceedings of the Eighth Workshop on
Hot Topics in Operating Systems (HotOS-VIII), pgs. 179. IEEE Computer Society, Maio de
2001. Uma verso estendida est disponvel em http://asc.di.fct.unl.pt/~nmp/papers/
hotos-extended.pdf.
[132] Nuno Preguia, J. Legatheaux Martins, Henrique Domingos, e Srgio Duarte. Supporting
groupware in mobile environments. Relatrio tcnico TR-04-2002 DI-FCT-UNL, Dep. Infor-
mtica, FCT, Universidade Nova de Lisboa, 2002.
[133] Nuno Preguia, Marc Shapiro, e J. Legatheaux Martins. Sqlicecube: Automatic semantics-based
reconciliation for mobile databases. Submitted for publication, 2003.
[134] Nuno Preguia, Marc Shapiro, e Caroline Matheson. Efcient semantics-aware reconciliation for
optimistic write sharing. Relatrio tcnico MSR-TR-2002-52, Microsoft Research, Cambridge
(UK), Maio de 2002. http://research.microsoft.com/scripts/pubs/view.asp?TR_ID=
MSR-TR-2002-5%2.
[135] Calton Pu e Avraham Leff. Replica control in distributed systems: An asynchronous approach.
Em SIGMOD Conference, pgs. 377386, 1991.
[136] Changtao Qu e Wolfgang Nejdl. Constructing a web-based asynchronous and synchronous col-
laboration environment using webdav and lotus sametime. Em Proceedings of the 29th annual
ACM SIGUCCS conference on User services, pgs. 142149. ACM Press, 2001.
[137] Michael Rabinovich, Narain H. Gehani, e Alex Kononov. Scalable update propagation in epi-
demic replicated databases. Em Peter M. G. Apers, Mokrane Bouzeghoub, e Georges Gardarin,
editores, Advances in Database Technology - EDBT96, 5th International Conference on Exten-
ding Database Technology, Avignon, France, March 25-29, 1996, Proceedings, volume 1057 de
Lecture Notes in Computer Science, pgs. 207222. Springer, 1996.
[138] Norman Ramsey e El od Csirmaz. An algebraic approach to le synchronization. Em Procee-
dings of the 8th European software engineering conference held jointly with 9th ACM SIGSOFT
international symposium on Foundations of software engineering, pgs. 175185. ACM Press,
2001.
BIBLIOGRAFIA 235
[139] David Ratner, Peter Reiher, Gerald J. Popek, e Geoffrey H. Kuenning. Replication requirements
in mobile environments. Mobile Networks and Applications, 6(6):525533, 2001.
[140] David Howard Ratner. Roam: A Scalable Replication System for Mobile and Distributed Com-
puting. Phd thesis, University of California, Los Angeles, Los Angeles, CA, USA, Janeiro de
1998.
[141] Benjamin Reed e Darrell D. E. Long. Analysis of caching algorithms for distributed le systems.
ACM SIGOPS Operating Systems Review, 30(3):1221, 1996.
[142] Qun Ren e Margaret H. Dunham. Using semantic caching to manage location dependent data in
mobile computing. Em Mobile Computing and Networking, pgs. 210221, 2000.
[143] Sean Rhea, Patrick Eaton, Dennis Geels, Hakim Weatherspoon, Ben Zhao, e John Kubiatowicz.
Pond: The oceanstore prototype. Em Proceedings of the 2
nd
USENIX Conference on File and
Storage Technologies (FAST03). USENIX Association, 2003.
[144] Tom Rodden. A survey of CSCW systems. Interacting with Computers, 3(3):319353, 1991.
[145] Mark Roseman e Saul Greenberg. Building real-time groupware with groupkit, a groupware
toolkit. ACM Transactions on Computer-Human Interaction (TOCHI), 3(1):66106, 1996.
[146] Antony I. T . Rowstron, Neil Lawrence, e Christopher M. Bishop. Probabilistic modelling of
replica divergence. Em Proceedings of the Workshop on Hot Topics in Operating Systems (Ho-
tOS-VIII), pgs. 5560, Maio de 2001.
[147] Yasushi Saito e Marc Shapiro. Replication: Optimistic approaches. Relatrio tcnico
HPL-2002-33, Hewlett-Packard Laboratories, Maro de 2002.
[148] Douglas S. Santry, Michael J. Feeley, Norman C. Hutchinson, Alistair C. Veitch, Ross W. Carton,
e Jacob Or. Deciding when to forget in the elephant le system. Em Symposium on Operating
Systems Principles, pgs. 110123, 1999.
[149] M. Satyanarayanan. Fundamental challenges in mobile computing. Em Proceedings of the f-
teenth annual ACM symposium on Principles of distributed computing, pgs. 17. ACM Press,
1996.
[150] SavaJe. Savaje os 1.1. http://www.savaje.com.
[151] Ycel Saygn, zgr Ulusoy, e Ahmed K. Elmagarmid. Association rules for supporting hoar-
ding in mobile computing environments. Em Proceedings of the 10
th
International Workshop on
Research Issues in Data Engineering, pgs. 7178, Fevereiro de 2000.
236 BIBLIOGRAFIA
[152] Michael D. Schroeder, Andrew D. Birrell, e Roger M. Needham. Experience with grapevine:
the growth of a distributed system. ACM Transactions on Computer Systems (TOCS), 2(1):323,
1984.
[153] Joo Costa Seco e Lus Caires. A basic model of typed components. Em Proceedings of the
ECOOP2000 14
th
European Conference on Object-Oriented Programming, volume 1850 de Lec-
ture Notes in Computer Science, pgs. 108128. Springer, Junho de 2000.
[154] Haifeng Shen e Chengzheng Sun. Flexible notication for collaborative systems. Em Proceedings
of the 2002 ACM conference on Computer supported cooperative work, pgs. 7786. ACM Press,
2002.
[155] Hyong Sop Shim, Robert W. Hall, Atul Prakash, e Farnam Jahanian. Providing exible services
for managing shared state in collaborative systems. Em Proceedings of the Fifth European Confe-
rence on Computer Supported Cooperative Work (ECSCW97), pgs. 237252. Kluwer Academic
Publishers, Setembro de 1997.
[156] Jorge Paulo F. Simo, Jos A. Legatheaux Martins, Henrique Joo L. Domingos, e Nuno Ma-
nuel R. Preguia. Supporting synchronous groupware with peer object-groups. Em Proceedings
of the Third USENIX Conference on Object-Oriented Technologies (COOTS), pgs. 233236, Por-
tland, Oregon, USA, Junho de 1997. Usenix Association.
[157] Sun. Jsr-000053 java servlet 2.3 specication. http://java.sun.com/products/servlet/.
[158] Chengzheng Sun. Undo any operation at any time in group editors. Em Proceedings of the 2000
ACM conference on Computer supported cooperative work, pgs. 191200. ACM Press, 2000.
[159] Chengzheng Sun e Clarence Ellis. Operational transformation in real-time group editors: issues,
algorithms, and achievements. Em Proceedings of the 1998 ACM conference on Computer sup-
ported cooperative work, pgs. 5968. ACM Press, 1998.
[160] Carl Tait, Hui Lei, Swarup Acharya, e Henry Chang. Intelligent le hoarding for mobile com-
puters. Em Proceedings of the rst annual international conference on Mobile computing and
networking, pgs. 119125. ACM Press, 1995.
[161] D. B. Terry, M. M. Theimer, Karin Petersen, A. J. Demers, M. J. Spreitzer, e C. H. Hauser.
Managing update conicts in bayou, a weakly connected replicated storage system. Em Proc. of
the 15
th
ACM Symposium on Operating systems principles, pgs. 172182. ACM Press, 1995.
[162] Douglas B. Terry, Alan J. Demers, Karin Petersen, Mike J. Spreitzer, Marvin M. Theimer, e
Brent B. Welch. Session guarantees for weakly consistent replicated data. Em Proceedings of the
BIBLIOGRAFIA 237
third international conference on on Parallel and distributed information systems, pgs. 140150.
IEEE Computer Society Press, 1994.
[163] Robert H. Thomas. A majority consensus approach to concurrency control for multiple copy
databases. ACM Transactions on Database Systems (TODS), 4(2):180209, 1979.
[164] A. Tridgell e P. Mackerras. The rsync algorithm. Technical Report TR-CS-96-05, The Australian
National University, Junho de 1996. Available from http://samba.anu.edu.au/rsync/.
[165] Manolis M. Tsangaris e Jeffrey F. Naughton. On the performance of object clustering techniques.
Em Proceedings of the 1992 ACM SIGMOD International Conference on Management of Data,
pgs. 144153. ACM Press, 1992.
[166] Lus Veiga e Paulo Ferreira. Incremental replication for mobility support in obiwan. Em Proc.
of the 22
nd
International Conference on Distributed Computing Systems (ICDCS02), pgs. 544.
IEEE Computer Society, Julho de 2002.
[167] Ins Vicente e Filipe Leito. Base de dados discogrca cooperativa. Relatrio do projecto nal
de curso, Departamento de Informtica, FCT, Universidade de Lisboa, 1999.
[168] Gary D. Walborn e Panos K. Chrysanthis. Supporting semantics-based transaction processing in
mobile database applications. Em Proceedings of the 14
th
Symposium on Reliable Distributed
Systems, pgs. 3140, 1995.
[169] WebGain. JavaCC: Java compiler compiler. http://www.webgain.com/products/java_cc/.
[170] William E. Weihl. Commutativity-based concurrency control for abstract data types. IEEE Tran-
sactions on Computers, 37(12):14881505, 1988.
[171] Seth J. White e David J. DeWitt. A performance study of alternative object faulting and pointer
swizzling strategies. Em Proceedings of the 18
th
International Conference on Very Large Data
Bases, pgs. 419431. Morgan Kaufmann, Agosto de 1992.
[172] Ouri Wolfson, Sushil Jajodia, e Yixiu Huang. An adaptive data replication algorithm. ACM
Transactions on Database Systems (TODS), 22(2):255314, 1997.
[173] Haifeng Yu e Amin Vahdat. Design and evaluation of a conit-based continuous consistency model
for replicated services. ACM Transactions on Computer Systems (TOCS), 20(3):239282, 2002.

NMP PHD

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

NMP PHD

Enviado por

Direitos autorais:

Formatos disponíveis

Universidade Nova de Lisboa

Faculdade de Cincias e Tecnologia

Sim, enquanto as reservas agregadas no violarem a restrio global.

Você também pode gostar