Conceitos básicos sobre provedores personalizados

O Microsoft Sync Framework inclui provedores para vários cenários de sincronização, como sincronização de arquivos, mas em alguns casos um provedor personalizado é necessário. Os provedores personalizados exigem que um desenvolvedor escreva mais código do que os provedores incluídos no Sync Framework, mas eles são um componente fundamental para a flexibilidade e extensibilidade do Sync Framework. Este tópico fornece informações que ajudam a entender o conceito de provedores personalizados e a fazer escolhas sobre qual tipo de provedor personalizado é apropriado para o seu aplicativo. Se você ainda não conhece o Sync Framework, recomendamos também que leia "Componentes do Sync Framework" em Selecionando os componentes apropriados do Sync Framework.

Noções básicas sobre o gerenciamento de provedores, aplicativos e metadados

O Microsoft Sync Framework sincroniza réplicas usando quatro componentes básicos: o tempo de execução de sincronização, uma sessão de sincronização e dois provedores de sincronização. Para sincronizar dados, um aplicativo cria uma sessão de sincronização e a transmite para um provedor de origem e um provedor de destino. A sessão usa o provedor de origem para obter novas alterações ocorridas na réplica de origem e usa o provedor de destino para aplicar essas alterações à réplica de destino. Um provedor mantém metadados, inclusive conhecimento, para cada réplica e para cada item que será sincronizado. O conhecimento é composto pelos metadados que descrevem todas as alterações que foram aplicadas a uma réplica, diretamente ou por sincronização.

Quando o Sync Framework não fornece um provedor para o repositório de dados a ser sincronizado, um provedor personalizado deve ser escrito. O Sync Framework inclui as APIs gerenciadas e não gerenciadas para dois tipos de provedores personalizados: provedores personalizados simples e provedores personalizados padrão:

• Devido a um número menor de interfaces e à simplicidade dessas interfaces, os provedores simples oferecem uma maior velocidade de desenvolvimento e suporte mais intuitivo para repositórios de dados em que faltam mecanismos de controle de alterações sofisticados.

• Os provedores padrão oferecem mais flexibilidade e níveis mais altos de desempenho e robustez.

Os dois tipos de provedores podem ser usados para sincronizar um ampla variedade de repositórios de dados; e eles fornecem opções em áreas importantes, como a filtragem e a manipulação de conflitos. Porém, existem diferenças importantes. Para obter mais informações, consulte "Decidindo entre um provedor simples e um provedor padrão" neste tópico.

A ilustração a seguir mostra os principais elementos usados em um cenário de sincronização. A ilustração é semelhante à do Selecionando os componentes apropriados do Sync Framework, mas o texto que acompanha fornece informações adicionais relevantes para provedores personalizados e mostra como os dados e os metadados fluem pelo sistema.

Os elementos da ilustração são de três tipos:

• Elementos escritos pelo desenvolvedor.

  • O aplicativo inicia a sincronização, responde aos eventos e trata outras tarefas com base nos requisitos do aplicativo. Para obter mais informações, consulte Implementando um aplicativo de sincronização.

  • O provedor gerencia os metadados para uma réplica e trabalha com o Sync Framework para enumerar alterações e detectar conflitos. O provedor também trabalha com o repositório de dados de uma réplica para enviar dados de item quando o provedor atua como o provedor de origem, bem como para aplicar alterações quando o provedor atua como o provedor de destino. O provedor é específico do tipo de dados que estão sendo sincronizados. Em geral, os dois provedores em uma sessão são do mesmo tipo, mas isso não é uma exigência. Para obter mais informações sobre interoperabilidade, consulte Integrando dados de provedores diferentes.

    Código gerenciado Um provedor simples implementa FullEnumerationSimpleSyncProvider ou AnchorEnumerationSimpleSyncProvider. Um provedor padrão implementa KnowledgeSyncProvider, IChangeDataRetriever e INotifyingChangeApplierTarget.

    Código não gerenciado Um provedor simples implementa IFullEnumerationSyncProvider ou IAnchorSyncProvider. Um provedor padrão implementa IKnowledgeSyncProvider, ISyncProvider, ISynchronousDataRetriever e ISynchronousNotifyingChangeApplierTarget (ou, para provedores assíncronos, as versões assíncronas).

  • O repositório de dados é qualquer repositório no qual você gravará um provedor.

  • O protocolo de transferência de dados determina como as alterações de dados são transmitidas entre dois provedores.

• Elementos fornecidos pelo Sync Framework.

  • Dependendo do tipo de código que será usado, gerenciado ou não gerenciado, o aplicativo se comunica com um orquestrador de sincronização (SyncOrchestrator) ou uma sessão de sincronização (ISyncSession) que então se comunica com cada provedor de sincronização, conduz o processo de sincronização e informa o status, os conflitos e os erros ao aplicativo cliente.

  • O tempo de execução de sincronização ajuda os provedores a executarem tarefas de sincronização comuns, como gerenciamento de metadados, detecção de conflitos e aplicação de alterações.

• Elementos que são escritos pelo desenvolvedor ou fornecidos pelo Sync Framework, dependendo dos requisitos de provedor e aplicativo.

  • O repositório de metadados contém os metadados usados pelo Sync Framework para determinar as alterações que cada provedor deve selecionar e aplicar ao repositório de dados que atende. O repositório de metadados pode estar separado do repositório de dados (como um arquivo separado ou banco de dados) ou integrado ao repositório (como uma tabela adicional em um banco de dados). Normalmente, o provedor de sincronização gerencia os metadados necessários à sincronização. Porém, dependendo da implementação da réplica, pode ser mais útil que algumas partes do gerenciamento de metadados sejam tratadas por um componente separado, como um serviço que limpa metadados antigos em horas programadas, e não durante a sincronização. Os metadados exigidos e o modo como eles operam e são armazenados dependem do tipo de provedor usado. Para obter informações sobre requisitos de metadados para cada tipo de provedor, consulte Gerenciando metadados para provedores simples e Requisitos de metadados para provedores padrão.

    O provedor simples protege o desenvolvedor, quase que completamente, de interagir com o repositório de metadados. Ele usa uma implementação de serviço de armazenamento de metadados fornecida com o Sync Framework. Os provedores personalizados padrão podem usar essa implementação ou podem: usar outra implementação com base na API do serviço de armazenamento de metadados; usar uma implementação completamente personalizada que armazena metadados em um repositório separado ou no repositório de dados. Para obter mais informações, consulte Gerenciando metadados para provedores padrão.

Decidindo entre um provedor simples e um provedor padrão

Na maioria dos casos, recomendamos que você use um provedor simples, mas primeiro você deve conhecer as suposições que foram feitas no design da API de provedor simples:

• Os repositórios de dados a serem sincronizados não suportam qualquer tipo de controle de alterações ou oferecem suporte apenas para o controle de alterações baseado em âncora.

  A âncora é um objeto que indica quais itens em um repositório de dados foram alterados desde a última sessão de sincronização. Em repositórios onde não há controle de alterações ou somente o controle de alterações baseado em âncora, as atualizações para o conhecimento de sincronização ocorrem durante a sessão de sincronização (de forma assíncrona), e não quando a alteração é feita no repositório (de forma síncrona). Isso poderá afetar o desempenho se ocorrerem muitas sessões de sincronização simultaneamente em uma réplica específica. Portanto, se um aplicativo exigir um alto índice de simultaneidade e se cada repositório de dados suportar atualizações síncronas do conhecimento de sincronização, use um provedor padrão.

• A réplica só requer que um tipo de item seja sincronizado.

• Devido às limitações dos repositório de dados ou aos requisitos de aplicativos, os metadados devem ser armazenados fora do repositório de dados.

  Os provedores simples armazenam metadados usando a implementação do serviço de armazenamento de metadados fornecida com o Sync Framework. Os metadados são armazenados separadamente dos dados que eles descrevem, o que acarreta dois possíveis problemas:

  • Se os metadados forem armazenados remotamente, eles poderão estar indisponíveis durante uma sessão de sincronização. Por exemplo, a conexão de rede entre as duas réplicas a serem sincronizadas está disponível, mas a conexão com o servidor que hospeda os metadados não está.

  • A consistência transacional entre dados e metadados não é garantida. É recomendável que os metadados sejam armazenados no mesmo computador que os dados, mas o suporte transacional só estará disponível se você usar um provedor padrão e armazenar os metadados no repositório de dados (ou usar uma transação distribuída para atualizar os dois repositórios). Vale lembrar que os provedores padrão também podem usar o serviço de armazenamento de metadados, mas isso não é uma exigência como no caso dos provedores simples.

Se seus requisitos de aplicativo estão de acordo com essas pressuposições, recomendamos que você use provedores simples. Para obter mais informações sobre provedores simples, consulte Implementando um provedor personalizado simples. Para obter mais informações sobre provedores padrão, consulte Implementando um provedor personalizado padrão.

Noções básicas sobre tipos de participantes do Sync Framework

O Sync Framework pode ser usado para sincronizar dados entre participantes de funcionalidades variadas. Um participante é um dispositivo ou serviço que pode sincronizar com outros sistemas que executam o Sync Framework.

O Sync Framework oferece suporte ao seguintes tipos de participantes:

• Participante completo

• Participante de proxy

• Participante parcial

• Participante simples

Participante completo

Um participante completo hospeda localmente o tempo de execução e armazena metadados. Os participantes completos podem participar de cenários de sincronização ponto a ponto, pois ambos os participantes podem iniciar a sincronização.

Dois participantes completos na sincronização ponto a ponto

Participante parcial

Um participante parcial pode armazenar metadados de sincronização, mas não pode processá-los. Um participante parcial depende de vários participantes completos para hospedar o tempo de execução e iniciar a sincronização. Os dados podem fluir através destes participantes, pois podem carregar os metadados de sincronização de vários mestres e comunicar esses metadados com qualquer outro participante completo. Os participantes parciais não podem participar de cenários ponto a ponto, pois não têm a capacidade para processar os metadados ou para hospedar o tempo de execução. Alguns exemplos de participantes parciais são unidades USB miniatura e telefones móveis que têm recursos de armazenamento de dados.

A ilustração a seguir mostra como um participante completo, no caso um computador, sincroniza com um participante parcial, um telefone móvel. O participante completo enumera ou filtra as alterações em nome do participante parcial e armazena os metadados no participante parcial. Isso permite que qualquer outro participante completo sincronize este participante parcial.

Participante completo sincronizando com um participante parcial

Participante simples

Um participante simples não armazena metadados, não pode hospedar o tempo de execução e pode não ter um controle de alterações. Em vez disso, um participante simples depende de um único participante completo para fazer tudo com relação a enumeração e aplicação de alterações, assim como com a manipulação e o armazenamento de metadados. Como um participante simples não pode armazenar metadados, este só pode agir como um nó folha que tem como parceiro um único participante completo que transfere dados para e de quaisquer outros participantes.

A ilustração a seguir mostra um participante completo que usa o serviço de armazenamento de metadados para armazenar metadados para um participante simples e que realiza todos os aspectos de sincronização em nome do participante simples. O repositório de metadados é usado para controlar alterações relacionadas ao participante simples, mas é armazenado no participante completo devido às limitações de armazenamento do participante simples.

Participante completo que usa o serviço de armazenamento de metadados para sincronizar um participante simples

Participante de proxy

Um participante de proxy inicia a sincronização de um provedor remoto tratando chamadas localmente e as encaminhando ao provedor remoto, como um banco de dados armazenado em um servidor.

Observação sobre segurança
O Sync Framework não fornece autenticação ou criptografia entre o provedor de proxy e o provedor remoto. Para ajudar a evitar acesso não autorizado ou violação, o canal de comunicação entre o provedor de proxy e o provedor remoto deve ser protegido usando uma autenticação mútua apropriada e um mecanismo de criptografia como protocolo SSL.

A ilustração a seguir mostra um provedor de participante completo sincronizando com um provedor de proxy. Observe que o provedor de proxy apenas envia comandos e metadados pela rede para o provedor remoto. O provedor remoto existe no servidor de banco de dados e implementa a lógica real usada para a sincronização. A linhas vermelha tracejada representa um limite do computador.

Participante completo sincronizando com um participante de proxy

A ilustração a seguir mostra como o Sync Framework pode ser usado para sincronizar provedores que são remotos com o aplicativo que inicia a sincronização. O aplicativo de controle poderia conectar dois serviços Web ou dispositivos inteligentes que devem estar sincronizados. Observe que ambos os provedores locais são provedores de proxy para os provedores remotos. As linhas vermelhas tracejadas representam limites do computador.

Aplicativo central sincronizando dois participantes de proxy

Consulte também

Outros recursos

Selecionando os componentes apropriados do Sync Framework

Implementando um provedor personalizado simples

Implementando um provedor personalizado padrão

Implementando um aplicativo de sincronização

Exemplos do Sync Framework