Compartir a través de


Aspectos básicos de los proveedores personalizados

Microsoft Sync Framework dispone de proveedores para diferentes escenarios de sincronización, como por ejemplo, la sincronización de archivos, aunque en algunos escenarios es necesario un proveedor personalizado. En los proveedores personalizados es necesario que un desarrollador escriba código adicional al de los proveedores que se incluyen en Sync Framework, pero estos proveedores constituyen un componente clave en la flexibilidad y extensibilidad de Sync Framework. En este tema se proporciona información que le ayudará a entender los proveedores personalizados y a tomar decisiones sobre el tipo de proveedor personalizado que es adecuado para su aplicación. Si carece de experiencia con Sync Framework, le recomendamos que lea también la sección "Componentes de Sync Framework" en Seleccionar los componentes apropiados de Sync Framework.

Introducción a la administración de proveedores, aplicaciones y metadatos

Microsoft Sync Framework sincroniza réplicas a través de cuatro componentes básicos: el tiempo de ejecución de la sincronización, una sesión de sincronización y dos proveedores de sincronización. Para sincronizar los datos, una aplicación crea una sesión de sincronización y le pasa un proveedor de origen y un proveedor de destino. La sesión utiliza el proveedor de origen para obtener los cambios nuevos que se han producido en la réplica de origen y el proveedor de destino para aplicar estos cambios en la réplica de destino. Un proveedor mantiene los metadatos, incluido el conocimiento, de cada réplica y cada elemento que se va a sincronizar. El conocimiento son los metadatos que describen todos los cambios que se han aplicado a una réplica, ya sea directamente o a través de la sincronización.

Cuando Sync Framework no proporciona ningún proveedor para que el almacén de datos se sincronice, debe escribirse un proveedor personalizado. Sync Framework contiene API administradas y no administradas para los dos tipos de proveedores personalizados: los proveedores personalizados simples y los proveedores personalizados estándar:

  • Gracias al menor número de interfaces y la sencillez de estas, los proveedores simples proporcionan una velocidad mayor de desarrollo y una compatibilidad más intuitiva con los almacenes de datos que carecen de sofisticados mecanismos de seguimiento de cambios.

  • Los proveedores estándar proporcionan la mayor flexibilidad y los niveles de rendimiento y solidez más elevados.

Estos dos tipos de proveedores se pueden utilizar para sincronizar una gran variedad de almacenes de datos y los dos proporcionan opciones en áreas importantes, como las operaciones de filtro y control de conflictos. Sin embargo, presentan diferencias importantes. Para obtener más información, vea la sección "Decidir entre un proveedor simple y un proveedor estándar" de este tema.

En la ilustración siguiente se muestran los principales elementos que se utilizan en un escenario de sincronización. La ilustración es similar a la de Seleccionar los componentes apropiados de Sync Framework, pero el texto que la acompaña proporciona más información acerca de los proveedores personalizados y muestra cómo los datos y los metadatos fluyen a través del sistema.

Arquitectura de los proveedores de sincronización personalizados

Los elementos de la ilustración son de tres tipos:

  • Elementos que escribe el desarrollador.

  • Elementos que se proporcionan a través de Sync Framework.

    • En función de si se utiliza código administrado o no administrado, la aplicación se comunica con un organizador de la sincronización (SyncOrchestrator) o una sesión de sincronización (ISyncSession), que, a continuación, se comunica con cada proveedor de sincronización, dirige el proceso de sincronización y comunica el estado, los conflictos y los errores a la aplicación cliente.

    • El tiempo de ejecución de la sincronización ayuda a los proveedores a realizar tareas de sincronización comunes, como la administración de los metadatos, la detección de conflictos y la aplicación de cambios.

  • Elementos escritos por el desarrollador o proporcionados por Sync Framework, en función de los requisitos del proveedor y la aplicación.

    • El almacén de metadatos contiene los metadatos que utiliza Sync Framework para determinar los cambios que debería seleccionar cada proveedor en el almacén de datos que abastece y aplicarlos a tal almacén de datos. El almacén de metadatos puede ser diferente del almacén de datos (como un archivo o base de datos independiente) o estar integrado en el almacén (como una tabla adicional de una base de datos). Normalmente, el proveedor de sincronización administra los metadatos que se requieren para la sincronización. Sin embargo, dependiendo de la implementación de la réplica, puede ser más útil para algunas partes de la administración de los metadatos ser tratados por un componente independiente, como un servicio que limpie los metadatos antiguos según una programación en lugar de durante la sincronización. Los metadatos necesarios y la forma en la que se almacenan y funcionan dependen del proveedor que se utilice. Para obtener información sobre los requisitos de los metadatos para cada tipo de proveedor, vea Administrar metadatos para proveedores simples y Requisitos de metadatos para proveedores estándar.

      Con el proveedor simple, el desarrollador apenas tiene que interactuar con el almacén de metadatos. Utiliza una implementación de Metadata Storage Service que se incluye con Sync Framework. Los proveedores personalizados estándar pueden utilizar esta implementación, aunque también pueden utilizar otra implementación en función de la API de Metadata Storage Service o una implementación totalmente personalizada que almacene los metadatos en un almacén independiente o en el almacén de datos. Para obtener más información, vea Administrar metadatos para proveedores estándar.

Decidir entre un proveedor simple y un proveedor estándar

En la mayoría de los casos, recomendamos utilizar un proveedor simple, aunque primero debe entender los supuestos bajo los que diseñamos la API de proveedor simple:

  • Los almacenes de datos que se van a sincronizar no admiten ningún tipo de seguimiento de cambios o solamente admiten el seguimiento de cambios basado en delimitadores.

    Un delimitador es un objeto que indica qué elementos de un almacén de datos han cambiado desde la última sesión de sincronización. En almacenes que no tienen seguimiento de cambios o solamente seguimiento de cambios basado en delimitadores, las actualizaciones del conocimiento de sincronización se producen durante la sesión de sincronización (asincrónicamente) y no cuando el cambio tiene lugar en el almacén (sincrónicamente). Esto puede afectar al rendimiento si muchas sesiones de sincronización se ejecutan simultáneamente en una réplica determinada. Por tanto, si una aplicación requiere una elevada simultaneidad y cada almacén de datos admite actualizaciones sincrónicas del conocimiento de sincronización, conviene utilizar un proveedor estándar.

  • La réplica solo necesita que se sincronice un tipo de elemento.

  • Por limitaciones del almacén de datos o por requisitos de la aplicación, los metadatos deben almacenarse fuera del almacén de datos.

    Los proveedores simples almacenan los metadatos utilizando la implementación de Metadata Storage Service que se incluye con Sync Framework. Los metadatos se almacenan aparte de los datos que describen, lo que representa dos posibles problemas:

    • Si los metadatos se almacenan de forma remota, no estarán disponibles durante una sesión de sincronización. Por ejemplo, la conexión de red entre las dos réplicas que se van a sincronizar está disponible, pero la conexión con el servidor que hospeda los metadatos, no.

    • La coherencia transaccional entre los datos y los metadatos no está garantizada. Se recomienda almacenar los metadatos en el mismo equipo que los datos, pero la compatibilidad transaccional no está disponible a menos que utilice un proveedor estándar y almacene los metadatos en el almacén de datos (o utilice una transacción distribuida para actualizar ambos almacenes). Tenga en cuenta que los proveedores estándar también pueden utilizar Metadata Storage Service, pero, al igual que en los proveedores simples, esto no es necesario.

Si los requisitos de la aplicación encajan bien en estos supuestos, le recomendamos que utilice los proveedores simples. Para obtener más información sobre los proveedores simples, vea Implementar un proveedor simple personalizado. Para obtener más información sobre los proveedores estándar, vea Implementar un proveedor estándar personalizado.

Introducción a los tipos de participantes de Sync Framework

Sync Framework se puede usar para sincronizar los datos entre participantes con una funcionalidad diversa. Un participante es un dispositivo o servicio que se puede sincronizar con otros sistemas que ejecutan Sync Framework.

Sync Framework admite los siguientes tipos de participantes:

  • Participante completo

  • Participante proxy

  • Participante parcial

  • Participante simple

Participante completo

Un participante completo hospeda el motor de tiempo de ejecución y almacena los metadatos localmente. Los participantes completos pueden tomar parte en escenarios de sincronización punto a punto porque ambos pueden iniciar la sincronización.

Dos participantes completos en la sincronización punto a punto

Componentes de participantes completos

Participante parcial

Un participante parcial puede almacenar metadatos de sincronización, pero no procesarlos. Un participante parcial se basa en varios participantes completos para hospedar el motor de tiempo de ejecución e iniciar la sincronización. Los datos pueden circular a través de estos participantes porque pueden llevar los metadatos de la sincronización con múltiples maestros y comunicar estos metadatos con cualquier otro participante completo. Los participantes parciales no pueden tomar parte en escenarios punto a punto debido a su incapacidad para procesar los metadatos u hospedar el motor de tiempo de ejecución. Algunos ejemplos de participantes parciales son las unidades de disco USB y los teléfonos móviles que tienen capacidades de almacenamiento de datos.

La ilustración siguiente muestra el modo en que un participante completo, por ejemplo un equipo, se sincroniza con un participante parcial, por ejemplo un teléfono móvil. El participante completo enumera o filtra los cambios en nombre del participante parcial y almacena los metadatos en el participante parcial. Esto permite que cualquier otro participante completo sincronice este participante parcial.

Sincronización de un participante completo con un participante parcial

Componentes de participantes completos y parciales

Participante simple

Un participante simple no almacena metadatos, no puede hospedar el motor de tiempo de ejecución y puede no disponer de la capacidad de seguimiento de cambios. En cambio, un participante simple se basa en un solo participante completo para llevar a cabo todo lo que tenga que ver con enumerar cambios, aplicarlos, y tratar y almacenar los metadatos. Dado que un participante simple no puede almacenar metadatos, sólo puede actuar como un nodo hoja que se asocia con un solo participante completo que realiza la transferencia de datos con cualquier otro participante.

La ilustración siguiente muestra un participante completo que utiliza Metadata Storage Service para almacenar metadatos de un participante simple y que controla todos los aspectos de la sincronización en nombre de este. El almacén de metadatos se utiliza para realizar el seguimiento de los cambios relacionados con el participante simple, pero se almacena en el participante completo debido a las limitaciones de almacenamiento del participante simple.

Participante completo que usa Metadata Storage Service para sincronizar un participante simple

Componentes de participantes completos y simples

Participante proxy

Un participante proxy inicia la sincronización para un proveedor remoto administrando las llamadas localmente y reenviándolas al proveedor remoto, como una base de datos que está almacenada en un servidor.

Security noteSeguridad Nota

Sync Framework no proporciona autenticación o cifrado entre el proveedor proxy y el proveedor remoto. Para ayudar a evitar el acceso no autorizado o la manipulación, el canal de comunicación entre el proveedor proxy y el proveedor remoto se debe proteger utilizando una autenticación mutua adecuada y un mecanismo de cifrado, como Capa de sockets seguros (SSL).

La ilustración siguiente muestra una sincronización del proveedor participante completo con un proveedor proxy. Observe que el proveedor proxy solo envía comandos y metadatos a través de la red al proveedor remoto. El proveedor remoto existe en el servidor de base de datos e implementa la lógica real que se utiliza para la sincronización. La línea roja con guiones representa el límite de un equipo.

Sincronización de un participante completo con un participante proxy

Componentes de participantes completos y participantes proxy

La ilustración siguiente muestra cómo se puede usar Sync Framework para sincronizar proveedores que son remotos a la aplicación que inicia la sincronización. La aplicación que lleva el control puede estar conectando dos servicios web o Smart Devices que se deben sincronizar. Observe que ambos proveedores locales son proveedores proxy para los proveedores remotos. Las líneas rojas con guiones representan los límites de los equipos.

Aplicación central que sincroniza dos participantes proxy

Componentes de participantes de aplicación y participantes proxy

Vea también

Conceptos

Seleccionar los componentes apropiados de Sync Framework
Implementar un proveedor simple personalizado
Implementar un proveedor estándar personalizado
Implementar una aplicación de sincronización
Ejemplos de Sync Framework