gestão de dados partilhados em ambientes de computação móvel

120 CAPÍTULO 8. RESERVAS
vc vl s vu e shvc shs
value-change (vc) não não não sim não não não
value-lock (vl) não sim não sim não não não
slot (s) não não não sim não não não
value-use (vu) sim sim sim sim sim sim sim
escrow (e) não não não sim sim ∗ não não
shared value-change (shvc) não não não sim não sim sim
shared slot (shs) não não não sim não sim sim
∗ Sim, enquanto as reservas agregadas não violarem a restrição global.
Tabela 8.1: Tabela de compatibilidade das reservas.
Um cliente móvel requisita uma conjunto de reservas do servidor antes de se desconectar. Este
conjunto deve ser definido com base nas operações que se espera serem efectuadas pelo utilizador até à
próxima interacção com o servidor. A dedução de bons valores para este problema pode ser vista como
uma extensão do problema da replicação antecipada [91, 87] (onde os clientes devem obter cópias dos
dados que os utilizadores vão aceder). Como se referiu anteriormente, este problema está fora do âmbito
desta dissertação e pode ser atacado usando técnicas de previsão [53].
Nas experiências apresentadas na secção 9.2 usou-se uma estratégia simples que adapta a previsão
do comportamento futuro do cliente com base no comportamento verificado. Esta estratégia permite
obter bons resultado numa aplicação de suporte a uma força de vendas móvel. A interface gráfica da
aplicação desenvolvida permite, adicionalmente, especificar as reservas que devem ser obtidas de forma
simples. Internamente as reservas são obtidas através de variantes da instrução select. Por exemplo,
para requisitar uma reserva escrow de três unidades relativa ao produto com o identificador 3, o cliente
submete a instrução get escrow reservation stock instances 3 from products where id=’5’.
Quando um cliente solicita uma reserva, o servidor verifica se é possível conceder a reserva. Primeiro,
o servidor verifica se existe alguma reserva concedida que impossibilite a concessão da nova reserva. Para
tal, usa-se a tabela de compatibilidade apresentada na tabela 8.1, em que sim significa que é possível
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 não se intersectarem, ambas podem ser concedidas.
Segundo, o servidor verifica se o utilizador do cliente móvel pode obter a reserva requisitada. Esta
verificação é efectuada com base em regras de autorização especificadas pelo administrador do sistema.
Estas regras especificam que reservas cada utilizador pode obter e por quanto tempo podem ser conce-
didas. A composição destas regras [33] pode ser simples e estática ou complexa recorrendo a funções
PL/SQL.
Quando uma reserva é concedida, o sistema Mobisnap tem de garantir que a promessa que lhe está