Introdução ao tempo de execução do Microsoft Sync Framework

Microsoft Corporation
Novembro de 2007

Conteúdo
Introdução
Participantes
    Tipos de participante
Microsoft Synchronization Framework
    Componentes principais
    Fonte de dados
    Metadados
    Fluxo de sincronização
    Exemplo de sincronização
    Exemplo de conflito
Resumo

Introdução

O Microsoft Sync Framework é uma abrangente plataforma de sincronização que permite a colaboração e acesso offline a aplicativos, serviços e dispositivos. Ele oferece as tecnologias e ferramentas que habilitam a mobilidade, o compartilhamento e a mudança dos dados para offline. Usando o Microsoft Sync Framework, os desenvolvedores podem criar ecossistemas sincronizados que são integrados com qualquer aplicativo, com quaisquer dados de qualquer armazenamento usando todos os protocolos em qualquer rede. 

Um aspecto fundamental do Microsoft Sync Framework é sua capacidade de criar provedores de sincronização personalizados. Um provedor é um componente de software que representa uma réplica da sincronização. Uma réplica é um repositório específico das informações a serem sincronizadas, como um sistema de arquivos em um dispositivo portátil. Ao representar uma fonte de dados, um provedor enumera as alterações de sua réplica. Ao representar um destino, um provedor aplica as alterações à sua réplica. Se os dados na fonte e no destino forem diferentes em relação ao tipo ou esquema, cada provedor executará o mapeamento ou transformação necessária. 

O Microsoft Sync Framework inclui vários provedores compatíveis com fontes de dados comuns. Embora você possa gravar provedores personalizados para essas fontes de dados, recomenda-se que, sempre que possível, você use os provedores que fornecemos. Isso pode minimizar o tempo de desenvolvimento e permitir que você reutilize o código testado existente. Os seguintes provedores são incluídos:

• Serviços de sincronização para ADO.NET: Sincronização para fontes de dados habilitados para ADO.NET
• Serviços de sincronização para sistemas de arquivos: Sincronização de arquivos e pastas
• Serviços de sincronização para SSE: Sincronização para SSE (Simple Sharing Extensions), como RSS e ATOM feeds

Em última análise, os desenvolvedores podem usar qualquer um dos provedores fornecidos ou podem criar provedores personalizados para trocar informações entre os dispositivos e aplicativos.

O objetivo do restante deste documento é ajudá-lo a compreender como o Microsoft Sync Framework permite que a sincronização crie uma topologia de sincronização. Descreveremos alguns dos principais conceitos relativos aos provedores de sincronização, que o ajudará a compreender como criar um provedor. Para obter informações mais detalhadas sobre o Microsoft Sync Framework, consulte https://msdn2.microsoft.com/en-us/sync/default.aspx.

Participantes

Antes de discutir os componentes específicos de um provedor, primeiro precisamos compreender os diferentes tipos de participantes de sincronização compatíveis com o Microsoft Sync Framework. Um participante é a combinação de um provedor e sua réplica associada. A réplica, que é o repositório das informações, a ser sincronizada seria qualquer item, desde um Web service a um laptop ou um pen drive USB. 

Tipos de participante

O Microsoft Sync Framework é compatível com três tipos de participantes: completo, parcial e simples. Um tipo de participante é definido por sua capacidade de armazenar e processar metadados de sincronização. Na pior das hipóteses, vamos supor que uma réplica seja capaz de retornar de forma programática informações quando solicitado. Essencialmente, o que precisa ser definido é se a réplica pode:

1. Habilitar informações a serem armazenadas e manipuladas no dispositivo existente ou no armazenamento de dados atuais; e
2. Permitir que os aplicativos (em nosso caso um serviço de sincronização) sejam executados diretamente do dispositivo

É importante distinguir os tipos de participantes que farão parte do ecossistema de sincronização porque ele nos informa se eles poderão armazenar as informações de estado necessárias pelo provedor, bem como nos informa se poderão executar o provedor diretamente do dispositivo. Essencialmente, o modelo de participação deve ser genérico. Como tal, um participante completo poderia ser configurado como sendo um participante parcial ou simples. 

Participantes completos

Os participantes completos são dispositivos que permitem que os desenvolvedores criem aplicativos e novos armazenamentos de dados diretamente no dispositivo. Os laptops e smartphones são exemplos de participantes completos, pois novos aplicativos podem ser executados diretamente do dispositivo e você também pode criar novos armazenamentos de dados para manter as informações, se necessário.

Participantes parciais

Os participantes parciais são dispositivos que têm a capacidade de armazenar dados no dispositivo.  No entanto, esses dispositivos não têm a capacidade de iniciar executáveis diretamente do dispositivo. Um fato importante sobre um participante parcial é que ele pode armazenar metadados necessários para a sincronização e, portanto, sincronizar com qualquer participante completo. Um exemplo de um participante parcial é um pen drive. Esses dispositivos atuam como um disco rígido, no qual as informações podem ser criadas, atualizadas ou excluídas. No entanto, eles geralmente não fornecem uma interface que permita que os aplicativos sejam executados neles diretamente. 

Participantes simples

Os participantes simples são dispositivos que são capazes de fornecer informações somente quando solicitado.  Esses dispositivos não podem armazenar nem manipular novos dados e não oferecem suporte à criação de novos aplicativos. Um participante simples depende de um participante completo para armazenar seus metadados (e, portanto, podem sincronizar somente com esse participante completo).

Os RSS Feeds e Web services fornecidos por uma organização externa, como Amazon ou EBay, são exemplos de participantes simples. Essas organizações podem permitir que você execute Web services e obtenha os resultados, mas eles não permitem que você crie seus próprios armazenamentos de dados ou execute seus próprios aplicativos em seus servidores Web. 

Resumo

Essencialmente, o objetivo do Microsoft Sync Framework é permitir que quaisquer fontes de dados sejam integradas independentemente do tipo de participante. Por esse motivo, os participantes simples e parciais podem sincronizar informações com participantes completos. Na pior das hipóteses, haverá necessidade de que um participante completo possa armazenar informações e iniciar o processo de sincronização.

Microsoft Synchronization Framework

Componentes principais

Antes de implementar a sincronização usando o Microsoft Sync Framework, precisamos primeiro compreender os componentes principais de um provedor de sincronização. Esses conceitos serão descritos mais detalhadamente nos exemplos de sincronização posteriormente no documento.

O diagrama a seguir mostra como um provedor se comunica com uma fonte de dados e recupera as informações de estado de um armazenamento de metadados. Esses provedores, por sua vez, comunicam-se com outros provedores por meio de uma sessão de sincronização.

Fonte de dados

A fonte de dados é a localização que armazena todas as informações que precisam ser sincronizadas. Uma fonte de dados poderia ser um banco de dados relacional, um sistema de arquivos, um Web service ou até mesmo uma fonte de dados personalizados incluída em uma linha de aplicativo empresarial. Desde que você possa acessar de forma programática os dados, será possível participar da sincronização.

Metadados

Um aspecto fundamental de um provedor é sua capacidade de armazenar informações sobre o armazenamento de dados e objetos nesse armazenamento de dados em relação às informações de estado e alteração. Os metadados podem ser armazenados em qualquer parte, seja em um arquivo, banco de dados ou armazenamento de dados de réplica existente.  Para uma maior comodidade, o Microsoft Sync Framework oferece uma implementação completa de um armazenamento de metadados incorporado no SQL Server Compact Edition. Esse armazenamento não é necessário, mas usá-lo significa que não você não precisará se preocupar em relação ao armazenamento de metadados de sincronização. 

Os metadados de um armazenamento de dados podem ser divididos em três componentes principais:

• Versões: Uma pequena quantidade de informações é armazenada para cada item sendo sincronizado, chamada de versões de item. Essas informações registram onde e quando um item foi alterado e a ID de item associada ao item. No caso de um banco de dados, um item pode ser a linha inteira em uma tabela. Alternativamente, um item pode ser uma coluna na linha de uma tabela.

  Quando um item for alterado, as informações armazenadas para essa alteração incluirão uma versão de criação e uma versão de atualização. Essas versões são compostas por dois componentes: uma contagem de tiques, que é um relógio lógico utilizado amplamente para identificar com exclusividade uma alteração; e uma ID de réplica, que é usada para identificar com exclusividade o armazenamento de dados que efetuou a alteração. A versão de criação é a mesma que a versão de atualização quando o item acaba de ser criado. As atualizações subseqüentes ao item modificam somente a versão atualizada. 

  Todo o controle de alterações deve ocorrer pelo menos no nível de itens. Em outras palavras, cada item deve ter uma versão independente.   O controle mais detalhado é extremamente desejável em alguns cenários, pois reduz o potencial de conflitos de dados (dois usuários atualizando o mesmo item em diferentes réplicas). O lado negativo é que ele aumenta a quantidade de informações de controle de alterações que são armazenadas.

  As duas principais formas nas quais um controle de versão pode ser implementado são:

  1. Controle interno: nesse método, as informações de controle de alterações de um item são atualizadas quando a alteração for feita. No caso de um banco de dados, por exemplo, um disparador pode ser usado para atualizar uma tabela de controle de alterações imediatamente depois que uma linha for atualizada.
  2. Controle assíncrono: nesse método, há um processo externo que é executado e verifica se há alterações. Quaisquer atualizações encontradas são adicionadas às informações de versão. Esse processo pode ser parte de um processo agendado ou pode ser executado antes da sincronização. Esse processo é geralmente usado quando não há mecanismos internos para atualizar automaticamente as informações de versão quando os itens são atualizados (p. ex., não há como injetar lógica no pipeline de atualização). Uma forma comum de verificar se há alterações é armazenar o estado de um item e compará-lo ao seu estado atual. Por exemplo, é possível verificar se o horário da última gravação ou tamanho do arquivo foi alterado desde a última sincronização.

• Conhecimento: o conhecimento é uma representação compacta das alterações de dados detectadas pela réplica. A finalidade do conhecimento é tornar a sincronização mais eficiente, pois ela ajuda a limitar a quantidade de informações que são enviadas entre as réplicas. À medida que as informações de versão são atualizadas, o conhecimento do armazenamento de dados também é atualizado. Os provedores usam o conhecimento de réplica para:

  1. Enumerar alterações: determina quais alterações não foram detectadas pela outra réplica.
  2. Detectar conflitos: determina quais operações foram feitas sem o conhecimento uma da outra.

• Marcas para exclusão: cada réplica também deve manter as informações de marca para exclusão de cada um dos itens que forem excluídos. Se as exclusões não forem controladas, um provedor não terá como informar que um item (como um arquivo) foi excluído. Nesse caso, o provedor não poderia propagar as informações de versão a outros provedores. Uma marca para exclusão deve conter as seguintes informações:

  • **ID global:  **ID de réplica e contagem de tiques usados para identificar com exclusividade o item de marca para exclusão em todas as réplicas.
  • Versão de exclusão: versão de atualização associada a um item de marca para exclusão
  • Versão de criação: ID de réplica e contagem de tiques associados quando o item foi originariamente criado

  Como as informações no log de marca para exclusão aumentarão com o tempo, convém ser prudente e criar um processo para limpar esse armazenamento depois de um período de tempo. A limpeza dos dados de marca para exclusão economiza espaço e pode ajudar a aprimorar o desempenho de sincronização. O suporte para o gerenciamento das informações de marca para exclusão é fornecido com o Microsoft Sync Framework.

Fluxo de sincronização

A réplica na qual a sincronização foi iniciada é chamada de origem e a réplica a qual se conecta é chamada de destino. As seguintes seções deste artigo descrevem o fluxo da sincronização, que é mostrado no diagrama a seguir. Para a sincronização bidirecional, esse processo será executado duas vezes, com a origem e o destino trocados na segunda iteração.

Sessão de sincronização iniciada com destino

Durante essa fase, é estabelecida uma sessão de sincronização, que cria um vínculo da fonte para o provedor.

O destino prepara e envia o conhecimento

Como discutido anteriormente, cada réplica armazena seu próprio conhecimento. O conhecimento armazenado no destino é passado para a origem.

O conhecimento de destino usado para determinar as alterações a serem enviadas

Por parte da origem, o conhecimento que acabou de ser recebido é comparado às versões de item local para definir os itens dos quais o destino não tem conhecimento. É importante observar que as versões que são enviadas não são os itens reais, mas um resumo de onde a última alteração foi feita em cada item. 

Conhecimento de origem e versões de alteração enviado para o destino

Assim que a origem tiver preparado a lista de versões de alteração necessária, elas serão transportadas para o destino

Versão local recuperada para itens de alteração e comparada em relação com a versão de origem e conhecimento

O destino usa as versões para preparar uma lista de itens que a origem precisa enviar. O destino também usa essas informações para detectar se há quaisquer conflitos de restrição. Os conflitos de restrição são conflitos que violam as restrições inseridas em itens, como o relacionamento de pastas ou o local de dados nomeados identicamente em um sistema de arquivos.

Os conflitos são detectados e solucionados ou adiados

Fundamentalmente, um conflito ocorre se for feita uma alteração no mesmo item em duas réplicas entre sincronizações. No tempo de execução do Microsoft Sync Framework, um conflito é detectado quando a versão de alteração em uma réplica NÃO tem o conhecimento da alteração das outras réplicas.   Um exemplo mais detalhado de como esse processo de detecção ocorre é descrito a seguir na seção “Exemplo de conflito”.

As réplicas têm liberdade para implementar uma variedade de diretivas para a resolução de itens em conflito em uma topologia de sincronização. Veja a seguir alguns exemplos de diretivas de resolução comumente usadas:

• Prioridade da fonte: as alterações feitas pela réplica de origem sempre têm prioridade quando for detectado um conflito.
• Prioridade do destino: as alterações feitas pela réplica de destino sempre têm prioridade.
• Mesclagem: mescla as duas alterações. As contagens de inventário são um exemplo de onde você deseja mesclar (somar) os valores juntos a partir de duas réplicas em vez de escolher uma como o valor correto.
• Conflito de log: registra ou adia o conflito.

Dados de item de solicitações de destino da origem

Durante essa fase, o destino determinou os itens na origem que precisam ser recuperados e comunica essa solicitação à origem.

A origem prepara e envia os dados de item

A origem capta a solicitação de dados de item e prepara os dados reais para que sejam transferidos ao destino. Se o item sendo controlado for uma linha em um banco de dados, essa linha será enviada. Se o item for um arquivo em uma pasta, então o arquivo será transferido.

Os itens são aplicados no destino

Os itens recebidos são considerados e aplicados no destino. Se ocorrerem quaisquer erros durante esse processo, como falha de rede, os itens serão marcados como exceções e corrigidos durante a próxima sincronização. O conhecimento recebido da origem é adicionado ao conhecimento do destino.

Exemplo de sincronização

Usando o fluxo de sincronização descrito na seção anterior, apresentaremos um exemplo de sincronização de arquivo que mostra como o Microsoft Sync Framework enumera as alterações e, em última análise, aplica os dados de item. Neste exemplo, há duas réplicas: réplica A e réplica B. A réplica A iniciará a sincronização com a réplica B (o que significa que a réplica A é a origem e a réplica B é o destino). Suponha que você queira sincronizar arquivos entre essas duas réplicas. O item a ser controlado é um arquivo único em uma pasta; ele é descrito como I_n (p. ex., I_1, I_2, I_3…).  Quando um novo arquivo (I₁) for criado, os metadados associados a esse arquivo precisarão ser atualizados da seguinte forma:

Item	Atualização Contagem de tiques	Atualização ID de réplica	Criação Contagem de tiques	Criação ID de réplica
I1	1	A	1	A

Se esse arquivo for atualizado novamente, a tabela de versão será semelhante ao seguinte:

Item	Atualização Contagem de tiques	Atualização ID de réplica	Criação Contagem de tiques	Criação ID de réplica
I1	5	A	1	A

No exemplo acima, a contagem de tiques de atualização foi definida como 5 porque o relógio lógico para a contagem de tiques foi amplo por origem, o que significa que a contagem de tiques 2 a 4 foi usada para alterações em outros itens na réplica. 

Por exemplo, no diagrama a seguir, vemos que há dois itens I adicionais₂ e I₃ na réplica que estão sendo controlados. Como você pode ver, as informações de versão aumentam à medida que cada vez mais itens são criados. O Microsoft Sync Framework não quer o armazenamento de versões de atualização anteriores. Ele precisa ter conhecimento somente da versão de atualização mais recente.

Item	Atualização Contagem de tiques	Atualização ID de réplica	Criação Contagem de tiques	Criação ID de réplica
I2	3	A	2	A
I3	4	A	4	A
I1	5	A	1	A

Se considerarmos o atual estado dos itens dessa réplica, representaríamos o conhecimento da réplica A da seguinte forma:

Conhecimento da réplica A = A₅

Como mencionado anteriormente, o conhecimento é uma representação compacta das alterações de dados detectadas pela réplica. Nesse caso, A é a identificação exclusiva atribuída a essa réplica e 5 é a contagem de tiques atual para a qual essa réplica tinha conhecimento das alterações. Se essa réplica tivesse sincronizado com quaisquer outras réplicas, veríamos esse conhecimento nessa lista.

Na réplica B, também há vários arquivos. Essa réplica seria semelhante ao seguinte:

Réplica B

Item	Atualização Contagem de tiques	Atualização ID de réplica	Criação Contagem de tiques	Criação ID de réplica
I104	2	B	1	B
I105	4	B	3	B

O atual conhecimento da Réplica B é:

Conhecimento da réplica B = B₄

Nesse ponto, escolhemos iniciar a sincronização entre as duas réplicas. A réplica A será a origem (a que iniciará a sincronização) e a réplica B será o destino.

Durante a sincronização, o destino envia seu conhecimento à origem.  Como mencionei anteriormente, o conhecimento para as duas réplicas será o seguinte:

Conhecimento da réplica A = A₅

Conhecimento da réplica B = B₄

A origem (Réplica A) recebe esse conhecimento e o utiliza para determinar quais versões enviar para o destino. Como a Réplica B não tem conhecimento de quaisquer itens na Réplica A, todo o conteúdo será enviado. Nesse caso, a Réplica incluiria as seguintes versões.

Lote de alterações da réplica A

Item	Atualização Contagem de tiques	Atualização ID de réplica	Criação Contagem de tiques	Criação ID de réplica
I2	3	A	2	A
I3	4	A	4	A
I1	5	A	1	A

O destino recebe essas versões e as enumera para determinar quais itens são solicitados pela origem. Ele também usa essas informações para definir se há quaisquer conflitos (p. ex., o mesmo arquivo foi atualizado em ambas as réplicas). 

Assim que tiver concluído, o destino solicita à origem que envie os itens dos quais ele não tem conhecimento. Nesse caso, a réplica A enviaria os arquivos associados a I_1, I₂ e  I_3.

O destino recebe esses arquivos e os adiciona à sua pasta. Os itens da réplica B agora incluirão itens recebidos da réplica A.

Réplica B – Tabelas de item atualizadas

Item	Atualização Contagem de tiques	Atualização ID de réplica	Criação Contagem de tiques	Criação ID de réplica
I104	2	B	1	B
I105	4	B	3	B
I2	3	A	2	A
I3	4	A	4	A
I1	5	A	1	A

No final dessa sincronização, o processo é executado mais uma vez, dessa vez a origem se tornará o destino e o destino se tornará a origem. Isso permite que a réplica A receba qualquer um dos arquivos que foram criados ou alterados na Réplica B (I₁₀₄ e  I₁₀₅).

No final da sincronização, ambas as réplicas tiveram o seguinte conhecimento atualizado.

Conhecimento da réplica A = A_5, B₄

Conhecimento da réplica B = A_5, B₄

Exemplo de conflito

Estendendo o exemplo anterior, as duas réplicas estão atualmente em “sinc” e cada uma das versões de item será semelhante ao seguinte:

Item	Atualização Contagem de tiques	Atualização ID de réplica	Criação Contagem de tiques	Criação ID de réplica
I104	2	B	1	B
I105	4	B	3	B
I2	3	A	2	A
I3	4	A	4	A
I1	5	A	1	A

Da mesma forma, o conhecimento para as duas réplicas será o seguinte:

Conhecimento da réplica A = A_5, B₄

Conhecimento da réplica B = A_5, B₄

Nesse ponto, ambas as réplicas decidem atualizar o mesmo arquivo (item I_4).

Na réplica A, a tabela de versão de item é atualizada para:

Item	Atualização Contagem de tiques	Atualização ID de réplica	Criação Contagem de tiques	Criação ID de réplica
I104	2	B	1	B
I105	4	B	3	B
I2	6	A	2	A
I3	4	A	4	A
I1	5	A	1	A

Na réplica B, a tabela de versão de item é atualizada para:

Item	Atualização Contagem de tiques	Atualização ID de réplica	Criação Contagem de tiques	Criação ID de réplica
I104	2	B	1	B
I105	4	B	3	B
I2	5	B	2	A
I3	4	A	4	A
I1	5	A	1	A

O conhecimento para as duas réplicas também será atualizado para:

Conhecimento da réplica A = A_6, B₄

Conhecimento da réplica B = A_5, B₅

Nesse ponto, a réplica A inicia a sincronização com a réplica B. Ignore a fase na qual a origem envia as versões de item e conhecimento para o destino. As seguintes etapas serão realizadas para o item I₂.

1. A réplica vê uma nova alteração de item para o item I₂ ou seja:

   Atualização Contagem de tiques	Atualização ID de réplica
   6	A

2. A réplica B analisa o conhecimento recebido da Réplica A (A6, B4) e determina que a Réplica A não estava ciente de uma alteração feita no mesmo item pela Réplica B:

   Atualização Contagem de tiques	Atualização ID de réplica
   5	B

3. Um conflito é detectado e passado ao aplicativo ou provador para que seja resolvido.

Como discutido anteriormente, o aplicativo tem a capacidade de escolher como gerenciar o conflito ou adiá-lo para resolução posterior. Se o conflito for adiado, ele ocorrerá durante a próxima sincronização e novamente até que seja resolvido. Assim que ele for resolvido, na próxima sincronização, a réplica original receberá o valor atualizado.

Resumo

O Microsoft Sync Framework inclui todos os itens necessários para a integração de aplicativos em uma rede baseada em colaboração ou offline, usando provedores pré-criados ou gravando novos provedores personalizados. Os provedores permitem que qualquer fonte de dados participe da sincronização de dados, independentemente do tipo de rede ou dispositivo.

Neste documento, abordamos os principais componentes que compõem o Microsoft Sync Framework. Em todo o documento apresentamos exemplos que mostram como o conhecimento é usado no Microsoft Sync Framework para permitir com eficiência que sejam armazenados dados para a troca de informações. Finalmente, vimos como o Microsoft Sync Framework permite a detecção de conflitos e que o aplicativo ou provedor resolva com eficiência conflitos por meio de vários mecanismos.

Ao usar essa estrutura, formamos a base da sincronização que pode ser estendida a qualquer dispositivo em qualquer armazenamento de dados usando uma topologia de rede. Podemos integrar facilmente fontes de dados disparadas para formar uma rede de mesmo nível e até mesmo estender armazenamentos de dados, nos quais não é possível alterar esquemas. 

Em última análise, o Microsoft Sync Framework fornece uma plataforma extremamente escalonável e que pode ser incorporada, habilitando a sincronização.

Para obter informações ou obter uma cópia do Microsoft Sync Framework CTP1 SDK, visite https://msdn2.microsoft.com/en-us/sync/default.aspx.