Para possibilitar um processo de sincroniza¸c˜ao eficiente, onde apenas as informa¸c˜oes modifi- cadas s˜ao transmitidas entre os dispositivos e o servidor, ´e necess´ario que os dois ambientes, m´ovel e fixo, implementem mecanismos para registrar as modifica¸c˜oes realizadas em suas ba- ses de dados durante os per´ıodos de desconex˜ao, conforme visto na Se¸c˜ao 3.6. As modifica¸c˜oes podem ser de trˆes tipos: inser¸c˜ao, atualiza¸c˜ao ou exclus˜ao de registros. Esta Se¸c˜ao detalha como esta quest˜ao ´e tratada no framework mSync.
4.3.1 Rastreamento de modifica¸c˜oes no dispositivo
O log de modifica¸c˜oes no dispositivo ´e mantido por meio de um campo de controle, chamado
statusReg, com a fun¸c˜ao especial de armazenar o estado de cada registro, que pode ser um
dos descritos a seguir:
1. Novo (New ): Registro inserido no dispositivo e ainda n˜ao sincronizado.
4. Framework mSync 45
3. Sincronizado (Synchronized ): Registro n˜ao modificado desde a ´ultima sincroniza-
¸c˜ao.
4. Exclu´ıdo (Removed ): Registro exclu´ıdo no dispositivo e ainda n˜ao sincronizado.
Durante a sincroniza¸c˜ao incremental (ver Se¸c˜ao 4.7) s˜ao transmitidos do dispositivo para o servidor apenas os registros nos estados novo, atualizado e exclu´ıdo. Ap´os a sincroniza¸c˜ao, os estados s˜ao modificados, de forma que os registros atualizados e novos fiquem com o estado sincronizado e os exclu´ıdos sejam removidos fisicamente da base de dados local.
4.3.2 Rastreamento de modifica¸c˜oes no banco de dados central
O processo de rastreamento de modifica¸c˜oes no banco de dados central, armazenado em um
servidor da rede fixa, n˜ao pode ser realizado por meio de flags de estado, como ´e feito nos bancos de dados m´oveis, pois diferente dos dispositivos que sincronizam informa¸c˜oes com um ´
unico servidor, o servidor da rede fixa deve ser capaz de sincronizar seus dados com v´arios dispositivos.
As ˆancoras de sincroniza¸c˜ao, apresentadas nas Se¸c˜oes 3.4 e 4.1, s˜ao utilizadas no rastrea- mento das modifica¸c˜oes. As tabelas do banco de dados central que suportam a sincroniza¸c˜ao incremental possuem um campo especial, chamado na arquitetura de idSyncChange, que ar- mazena o valor da ˆancora vigente no momento em que um registro ´e inserido ou atualizado. O esquema proposto n˜ao faz distin¸c˜ao entre inser¸c˜oes e atualiza¸c˜oes, de forma que o campo idSyncChange deve ser atualizado no momento em que um registro ´e criado ou modificado.
O log de exclus˜ao de registros ´e implementado por meio de uma tabela conhecida na
literatura como tombStone (MicrosoftSyncServices (2008); SyncML Protocol (2001)). Sempre que um registro ´e exclu´ıdo no banco de dados central, deve ser criada uma nova linha na tombStone para registrar o evento. A figura 4.4 apresenta a estrutura da tabela tombStone utilizada pelo mSync, cujos campos possuem as fun¸c˜oes especificadas a seguir:
codTable: C´odigo da tabela de onde o registro foi exclu´ıdo. GUId: Identificador ´unico global do registro.
idSync: Valor da ˆancora de sincroniza¸c˜ao, referente `a tabela de onde o registro foi exclu´ıdo, no momento da exclus˜ao.
idDeviceRemove: Identificador do dispositivo que excluiu o registro. dtRemove: Data em que o registro foi exclu´ıdo.
Durante a sincroniza¸c˜ao incremental, o servidor envia para o dispositivo apenas os regis- tros cujo idSyncChange seja igual ou maior do que a ˆancora da ´ultima sincroniza¸c˜ao realizada
pelo dispositivo e menor do que a ˆancora da sincroniza¸c˜ao atual. Isso garante que apenas
os registros inseridos ou atualizados no servidor, ap´os a ´ultima sincroniza¸c˜ao, ser˜ao envi- ados para o dispositivo. A figura 4.5 ilustra este processo, onde apenas os registros cujo
4. Framework mSync 46 tombStone codTable int <pk> GUId int <pk> idSync int dtRemove datetime idDeviceRemove int
Figura 4.4: Estrutura da tabela tombStone
idSyncChange seja maior ou igual 54 e menor do que 70 s˜ao transmitidos do servidor para o dispositivo durante a sincroniza¸c˜ao de dados.
Figura 4.5: Exemplo do uso de ˆancoras no rastreamento de modifica¸c˜oes
Os registros exclu´ıdos no servidor s˜ao tratados de forma an´aloga, sendo enviados para o dispositivo apenas os registros da tombStone cujo idSync seja igual ou maior do que a ˆancora da ´ultima sincroniza¸c˜ao realizada pelo dispositivo e menor do que a ˆancora da sincroniza¸c˜ao atual.
4.3.2.1 O efeito eco na sincroniza¸c˜ao de dados
A arquitetura mSync realiza um tratamento para evitar que as modifica¸c˜oes enviadas pelo
dispositivo na primeira fase da sincroniza¸c˜ao (ver Se¸c˜ao 4.7), sentido DM (Dispositivo M´o- vel) para SF (Servidor Fixo), sejam transmitidas de volta para o DM na segunda fase da sincroniza¸c˜ao, sentido SF para DM, o que, neste trabalho, ´e denominado efeito eco.
Essa situa¸c˜ao ocorre porque quando o dispositivo envia as modifica¸c˜oes para o servidor fixo, no momento em que os registros s˜ao inseridos ou atualizados na base de dados central, o seu idSyncChange ´e atribu´ıdo com o valor da ˆancora de sincroniza¸c˜ao atual referente `a tabela
4. Framework mSync 47
sincronizada. Assim, na segunda fase da sincroniza¸c˜ao, quando o servidor envia as modifica- ¸c˜oes para o dispositivo, esses registros ter˜ao um idSyncChange igual ou maior do que a ˆancora da ´ultima sincroniza¸c˜ao realizada pelo dispositivo e menor do que a ˆancora da sincroniza¸c˜ao atual e, portanto, conforme explicado anteriormente, ser˜ao enviados desnecessariamente para o dispositivo.
Para evitar esta ocorrˆencia, o framework registra na base de dados central o c´odigo do dispositivo que inseriu, atualizou ou excluiu cada registro. Desta forma, durante a segunda fase da sincroniza¸c˜ao, s˜ao enviados para o dispositivo apenas os registros modificados (in- seridos, atualizados ou exclu´ıdos) cujo c´odigo do dispositivo que realizou a modifica¸c˜ao seja diferente do c´odigo do dispositivo que est´a sincronizando.
Deve-se garantir que quando as modifica¸c˜oes na base de dados central n˜ao forem rea-
lizadas durante a sincroniza¸c˜ao com os dispositivos, o c´odigo do dispositivo que realizou a modifica¸c˜ao seja atribu´ıdo com o valor zero. Esse procedimento ´e importante pois, caso n˜ao
seja realizado, um dispositivo que inseriu ou atualizou um determinado registro n˜ao rece-
ber´a as novas modifica¸c˜oes realizadas na base de dados central por outras fontes, que n˜ao as sincroniza¸c˜oes.
4.3.2.2 M´etodo n˜ao intrusivo para rastreamento de modifica¸c˜oes no banco de
dados central
Em algumas situa¸c˜oes, principalmente quando a solu¸c˜ao m´ovel est´a sendo integrada a sistemas legados, n˜ao ´e poss´ıvel alterar a estrutura das tabelas existentes no banco de dados central para inserir os campos utilizados no processo de manuten¸c˜ao do log de altera¸c˜oes.
Nestas situa¸c˜oes, as informa¸c˜oes referentes ao valor da ˆancora de sincroniza¸c˜ao atual e o identificador do dispositivo que realizou cada modifica¸c˜ao no banco de dados central podem ser armazenadas em uma tabela de dados separada, criada especialmente para este fim, com estrutura semelhante `a exibida na figura 4.6.
cntrChanges
codTable int <pk> GUId int <pk> idSyncChange int
idDeviceChange int
Figura 4.6: Estrutura da tabela de controle de altera¸c˜oes
Essa abordagem evita a necessidade de altera¸c˜oes na estrutura de tabelas j´a existentes, mas em contrapartida, cria um overhead para o sistema nas opera¸c˜oes de inser¸c˜ao e atualiza- ¸c˜ao de registros. Durante a sincroniza¸c˜ao, os mesmos crit´erios j´a apresentados para selecionar os registros que ser˜ao enviados para o dispositivo continuam v´alidos, por´em agora ´e necess´ario realizar um join com a tabela de controle de altera¸c˜oes para que eles possam ser aplicados.
4. Framework mSync 48