Visão geral e cenários

O Sync Framework permite a sincronização entre bancos de dados. Ele possui uma API intuitiva e flexível que permite criar aplicativos designados para cenários offline e de colaboração. A API permite que você use todos ou apenas alguns componentes fornecidos, dependendo da arquitetura e dos requisitos de um aplicativo. O Sync Framework oferece suporte a topologias cliente-servidor, cliente-cliente e mistas. Nas topologias cliente-servidor, todos os clientes são sincronizados com um servidor central. Nas topologias cliente-cliente, cada cliente pode ser sincronizado com outro cliente sem que as alterações precisem passar por um servidor central. As topologias mistas são uma combinação de topologias cliente-cliente e cliente-servidor.

Comparando o Sync Framework com outras tecnologias

A Microsoft oferece várias tecnologias projetadas para aplicativos que executam sincronização. A tecnologia mais importante para comparação em termos de sincronização ponto a ponto é a replicação transacional ponto a ponto. Ela é usada para sincronizar dois ou mais bancos de dados do SQL Server Enterprise. Embora ela seja útil para comparar as duas tecnologias, lembre-se de que a replicação transacional ponto a ponto foi criada para a sincronização servidor/servidor que fornece escalabilidade e alta disponibilidade. O Sync Framework foi criado para sincronização cliente/servidor e cliente/cliente que suporta aplicativos de colaboração.

Use a tabela a seguir para ajudar a determinar qual tecnologia é adequada para os aplicativos que você deseja criar.

1 Os bancos de dados podem trocar informações com outras fontes de dados para as quais o Sync Framework dá suporte, como serviços Web, sistemas de arquivos ou repositórios de dados personalizados.

2 O Sync Framework usa controle de alterações líquidas no qual a última versão de uma linha é sincronizada. Com a replicação transacional ponto a ponto, todas as alterações em uma linha são aplicadas a cada par.

3 A replicação fornece resolução de conflitos internos; enquanto o Sync Framework fornece uma estrutura para criar o esquema de resolução de conflitos.

O Sync Framework fornece a flexibilidade de um modelo de programação, como conjuntos de dados offline e um conjunto de recursos de sincronização valioso, como aquele encontrado na replicação de mesclagem. A replicação é destinada a administradores de banco de dados e foi projetada para sincronizar bancos de dados do SQL Server. A replicação oferece uma funcionalidade importante com configuração disponível por meio de assistentes, procedimentos armazenados e sua própria API. O Sync Framework se destina a desenvolvedores e dá suporte à sincronização com outros tipos de repositórios de dados e à sincronização através de serviços, como o WCF (Windows Communication Foundation).

Para alguns aplicativos, a decisão de usar uma tecnologia é fácil: se você deve ter componentes separados para habilitar a sincronização por diferentes transportes ou serviços, ou sincronizar uma fonte de dados que não seja um banco de dados, o Sync Framework é a solução. Se você for um administrador de banco de dados que está criando um sistema para escalabilidade e alta disponibilidade, ou que deseja configurar sincronização sem muita programação, a replicação é a melhor opção. Essencialmente, você deve considerar com atenção os requisitos do aplicativo e determinar se a API Sync Framework é a tecnologia adequada a ser usada. Se desejar ir além da replicação de um esquema e de seus dados de um banco de dados para outro, procure usar o Sync Framework.

Cenários de sincronização

A capacidade de dar suporte a trabalhadores móveis e remotos está se tornando cada vez mais importante para as organizações. As organizações devem garantir que os trabalhadores tenham acesso às mesmas informações que teriam se estivessem no escritório. Na maior parte dos casos, esses usuários terão um laptop, um desktop no escritório, um smartphone ou um PDA. Nesses dispositivos, às vezes, os usuários podem acessar dados usando uma conexão VPN ou algum outro método de conexão direta com a rede corporativa. Para a maioria dos usuários remotos, esta solução não é satisfatória devido às grandes desvantagens nas seguintes áreas:

• Requisitos de rede

  Para que os usuários possam acessar informações, o dispositivo remoto deve ter uma conexão constante com a rede corporativa durante o acesso aos dados. Para alguns trabalhadores, como os que trabalham de casa, isso talvez não seja um problema. Mas para outros usuários, como os vendedores que estão constantemente em movimento, isso poderia ser mais difícil. Por exemplo, se um vendedor estiver visitando um cliente e não puder acessar os dados do estoque porque não há conectividade de rede, seu trabalho será prejudicado.

• Velocidade de acesso aos dados

  Em um ambiente típico de cliente-servidor corporativo, os usuários têm redes de alta velocidade que permitem o acesso rápido a informações. Porém, os trabalhadores remotos frequentemente se conectam a redes lentas e não confiáveis. Usando uma solução comum, cada fragmento de dados que um usuário desejar acessar deverá ser baixado sempre que solicitado, pois não é possível manter os dados no dispositivo. Por exemplo, se um vendedor precisar baixar sua lista de produtos toda vez que abrir o aplicativo, o tempo de retardo para popular o aplicativo com as informações poderá ser desanimador.

• Ponto de falha único

  Com esse tipo de solução, normalmente os usuários contam com um único banco de dados de servidor. Se esse banco de dados não estiver disponível devido a um período de inatividade planejado ou a falhas do servidor, todos os trabalhadores remotos serão desconectados de seus dados.

• Escalabilidade de servidor

  À medida que mais pessoas trabalham remotamente, o desempenho dos servidores corporativos é afetado e maior é a necessidade de adição de hardware.

Aplicativos ocasionalmente conectados

Uma alternativa para a solução descrita na seção anterior é a implementação de um aplicativo ocasionalmente conectado. Um aplicativo ocasionalmente conectado ainda permite que um trabalhador remoto acesse dados, mas as informações desejadas são armazenadas localmente. Para popular um banco de dados local, um aplicativo ocasionalmente conectado usa, em geral, a sincronização de dados.

A sincronização de dados consiste na capacidade de obter periodicamente as informações armazenadas em um banco de dados (como o banco de dados de um cliente) e sincronizar as alterações com outro banco de dados (como o banco de dados de um servidor). Com uma solução baseada em sincronização, o usuário não precisa mais ter uma conexão de rede constante para acessar as informações. Como os dados são armazenados localmente, o usuário tem acesso constante aos dados enquanto o processamento é descarregado a partir do banco de dados central. Além disso, visto que a velocidade da rede não é mais um fator de restrição, o usuário agora pode acessar os dados na velocidade do computador local.

As sincronizações cliente-cliente evitam o único ponto de falha habilitando a sincronização que não depende da passagem de todas as alterações por um servidor. A capacidade de enviar por push grande parte do processamento do aplicativo para cada cliente também ajuda a solucionar o problema da escalabilidade do servidor.

O Sync Framework usa provedores de sincronização para se comunicar com cada banco de dados que é sincronizado. Os provedores de banco de dados do Sync Framework, que são parecidos com os provedores de dados do ADO.NET, protegem outros componentes do Sync Framework da implementação específica de cada banco de dados. O Sync Framework inclui cinco provedores de banco de dados que oferecem suporte a dois tipos de cenários: offline e de colaboração. A ilustração a seguir mostra um cenário offline: em uma topologia cliente-servidor, os clientes se conectam a um servidor central para sincronizar dados quando uma conexão está disponível.

Uma extensão comum desse tipo de aplicativo ocasionalmente conectado é a possibilidade de oferecer suporte a cenários de colaboração. São cenários nos quais dois bancos de dados podem ser sincronizados ponto a ponto, sem ter que passar por um hub central. A ilustração a seguir mostra uma topologia mista, na qual um servidor central é sincronizado com clientes e os clientes podem sincronizar entre si. Uma topologia assim poderia oferecer suporte a um aplicativo que permita aos usuários compartilhar notas do projeto. Os membros da equipe do projeto geralmente exigem uma cópia local dos dados com a qual eles possam trabalhar. Depois de fazer as alterações, eles podem fazer a sincronização com um servidor para carregar as alterações ou com outro membro da equipe para trocar alterações.

Provedores de sincronização de banco de dados

Estes são os três principais provedores de sincronização de banco de dados incluídos no Sync Framework:

• SqlSyncProvider - usado para sincronizar bancos de dados do SQL Server.

• SqlCeSyncProvider - usado para sincronizar bancos de dados do SQL Server Compact.

• DbSyncProvider - costuma ser usado para sincronizar bancos de dados que não são do SQL Server.

Esses provedores apresentam as seguintes características:

• Adequados para topologias cliente-servidor, ponto a ponto e mistas.

• Podem ser usados de maneiras mais flexíveis. Por exemplo, você pode sincronizar duas instâncias de DbSyncProvider ou uma instância de SqlSyncProvider e um instância de SqlCeSyncProvider, e assim por diante.

• Usam metadados do Sync Framework e podem participar de topologias com outros provedores do Sync Framework.

Para obter mais informações sobre a sincronização de dados, consulte Cenários de sincronização de banco de dados.

Dois provedores de sincronização de banco de dados adicionais foram incluídos para dar suporte apenas a cenários offline. Esses provedores foram substituídos pelos provedores descritos anteriormente, que dão suporte a cenários offline e de colaboração. Eles foram incluídos nesta documentação como referência para aplicativos existentes que os utilizam. Para desenvolver novos aplicativos, use os provedores descritos anteriormente.

Os provedores apenas offline são:

• DbServerSyncProvider

• SqlCeClientSyncProvider

Esses provedores apresentam as seguintes características:

• Adequados para topologias cliente-servidor.

• Sempre são usados como um par. Por exemplo, você não pode sincronizar dois bancos de dados de servidor usando duas instâncias de ServerSyncProvider (em vez disso, use SqlSyncProvider ou DbSyncProvider).

• Eles podem ser menos complexos que os provedores de colaboração, mas não podem participar de topologias com outros provedores do Sync Framework.

Para obter mais informações sobre a sincronização offline, consulte Cenários apenas offline.

Consulte também

Outros recursos

Sincronizando bancos de dados