Microsoft Sync Framework

Microsoft Sync Framework es una plataforma de sincronización que permite la colaboración de aplicaciones desconectadas, servicios y dispositivos. Los desarrolladores pueden construir ecosistemas de sincronización que integren cualquier aplicación, cualquier dato de cualquier almacenamiento usando cualquier protocolo sobre cualquier red. Las características tecnológicas de Sync Framework y sus herramientas permiten el roaming, compartir y tomar datos en línea.

Un aspecto clave de Sync Framework es la habilidad para crear proveedores personalizados. Los proveedores permiten que cualquier origen de datos pueda participar en el proceso de sincronización de Sync Framework, permitiendo que ocurra la sincronización punto a punto (peer-to-peer).

Un número de proveedores son incluidos en Sync Framework que soportan muchos orígenes de datos. Aunque no se requiere, para minimizar el desarrollo es recomendable que los desarrolladores usen estos proveedores donde sea posible. Los siguientes proveedores son incluidos:

• Proveedores de sincronización de base de datos: La sincronización por ADO.NET- permite orígenes de datos (data sources).
• Proveedores de sincronización de archivos: Permite la sincronización de archivos y carpetas.
• Componentes de sincronización web: Permite la sincronización para FeedSync tal como RSS y ATOM.

Los desarrolladores últimamente usan cualquiera de los proveedores out-of-the-box o pueden crear proveedores personalizados para intercambiar información entre dispositivos y aplicaciones.

El objetivo de este documento es ayudar a entender como Microsoft Sync Framework permite la sincronización. En este documento se detallaran algunos conceptos clave que formaran las bases de cómo crear un proveedor. Para ver información más detallada puede visitar http://msdn.microsoft.com/sync (inglés)

Participantes

Antes de comentar sobre los componentes específicos de un proveedor, primero necesitamos entender los diferentes tipos de participantes que pueden ser soportados. Un participante es la localización o lugar de donde se reciben los orígenes de datos. Un participante puede ser cualquier cosa por ejemplo un web service, una laptop, o una unidad flash USB.

Tipos de participantes

Basado en las capacidades del dispositivo, la manera en que cada proveedor integra puede variar. Por lo menos, asumiremos que el dispositivo es capaz de programablemente regresar información cuando le es solicitada. En última instancia, lo que necesitamos determinar es si el dispositivo puede:

1. Permitir que la información pueda ser almacenada y manipulada ya sea en el dispositivo existente o en el almacén de datos actual y
2. Permitir que las aplicaciones (en nuestro caso el proveedor de sincronización) puedas ser ejecutadas directamente del dispositivo.

Es importante distinguir los tipos de participantes que serán parte del ecosistema de sincronización porque ellos nos dicen si serán capaces de almacenar el estado de la información requerida por el proveedor y también puede decirnos si ejecutaremos el proveedor directamente del dispositivo. Por último, el participante modelo será el genérico. Como tal, un participante completo puede ser configurado como parcial o participante simple.

Participantes totales

Los participantes totales son dispositivos que permiten crear aplicaciones y nuevos orígenes de datos (data sources) directamente en los dispositivos. Una laptop o un Smartphone son ejemplos de participantes totales porque las nuevas aplicaciones pueden ser ejecutadas de los dispositivos y puedes también crear almacenamientos de datos persistentes de información si es requerido.

Participantes parciales

Los participantes parciales son dispositivos que tienen la habilidad de almacenar datos ya sea en los data sources o en otro almacén de datos del dispositivo. Estos dispositivos, no tienen la habilidad para poner en marcha los ejecutables directamente desde el dispositivo. Algunos ejemplos de estos participantes son las unidades flash o las tarjetas SD. Estos dispositivos actúan como un disco duro donde la información puede ser creada, actualizada o eliminada. De todas maneras, estos dispositivos típicamente no dan una interface que permita a las aplicaciones ser ejecutadas directamente en ellos.

Participantes simples

Los participantes simples son dispositivos que son solamente capaces de proveer información cuando se les es requerida (bajo petición). Estos dispositivos no pueden almacenar o manipular nuevos datos y son incapaces de soportar la creación de nuevas aplicaciones. Los feeds RSS y los proveedores de Web Services por una organización externa tal como Amazon o EBay son ambas ejemplos de participantes simples. Estas organizaciones pueden brindar la oportunidad para ejecutar un web service y obtener resultados de vuelta, de todas maneras, no brindan la oportunidad de de crear almacenamientos de datos propios y tampoco dan la capacidad de poder ejecutar tus propias aplicaciones en sus servidores web.

Teniendo todo junto

La meta final de Microsoft Sync Framework es proveer un origen de datos para ser integrado independientemente del tipo de participante. Por esta razón, los participantes parciales pueden sincronizar información con los participantes totales y los participantes totales pueden hacerlo con los participantes simples. Por lo menos debe haber un participante.

Microsoft Sync Framework

Componentes del núcleo

Antes de implementar la sincronización usando Sync Framework, necesitamos comprender los componentes claves de un proveedor. El siguiente diagrama muestra como un proveedor construido usando Sync Framework se comunica con un data source y recupera información de estado de un almacenamiento de metadatos. Estos proveedores se comunican a su vez con otros proveedores a través de una sesión de sincronización.

Data Source (origen de datos)

El data source es la localización donde toda la información la cual necesita ser sincronizada es almacenada. Un data source puede ser una base de datos relacional, un archivo, un web service o hasta un data source personalizado incluido en una aplicación de negocios (business application). Mientras puedas programar el acceso a datos éste puede participar en la sincronización.

Metadatos

Un componente fundamental de un proveedor es la habilidad para almacenar información sobre los datos almacenados y los objetos dentro de este almacén de datos con respecto al estado y cambio de información. Los metadatos pueden ser almacenados en un archivo, dentro de una base de datos o dentro de un data source donde se sincronizan. Como una conveniencia opcional, Sync Framework ofrece una completa implementación de una construcción de almacenamiento de metadatos en una ligera base de datos que se regresa en tu proceso. Los metadatos para un almacenamiento de datos pueden dividirse en cinco componentes:

• Versiones
• Knowledge
• Conteo de Ticks
• Replica de ID
• Tombstones

Para cada elemento sincronizado, una pequeña cantidad de información es almacenada la cual describe donde y cuando el elemento cambió. Este metadato es compuesto de dos versiones: Versión de creación y versión de actualización. Una versión es compuesta por dos componentes: un conteo de ticks asignado por el almacén de datos y la réplica de ID por el almacén de datos también. Cuando los elementos son actualizados, el actual conteo de ticks es aplicado para ese elemento y (el conteo de ticks) se incrementa en el almacén de datos. La réplica de ID es un único valor que identifica un almacén de datos en particular. La creación de versión es la misma que la versión de actualización cuando el elemento es creado. Subsecuentemente las actualizaciones del elemento modifican la versión de actualización.
Las dos principales maneras en que el versionamiento puedes ser implementado son:

1. Seguimiento en línea (inline tracking): En este método cambia el seguimiento de la información cuando el elemento es actualizado y el cambio realizado.
2. Seguimiento asíncrono: En este método, hay un proceso externo que regresa y busca cambios. Cualquier actualización encontrada es agregada a la información de la versión. Este proceso puede ser parte de un proceso programado o puede ser ejecutado antes de la sincronización. Este proceso es típicamente usado cuando no hay mecanismos internos para actualizar automáticamente la información de versión en el momento que los elementos son actualizados. Una manera común para revisar los cambios es almacenando el estado de un elemento y compararlo con el estado actual. Por ejemplo, se podría revisar si “la última vez que se escribió” o el tamaño del archivo ha cambiado desde la última actualización.

Todo cambio debe ocurrir por lo menos a nivel de elementos. En otras palabras, cada elemento debe tener una versión independiente. En caso de una base de datos, un elemento podría ser un registro (reglón) entero dentro de una tabla. Adicionalmente, un elemento podría ser una columna en un registro de una tabla. En caso de un de sincronización de archivos, un elemento podría ser un archivo. Seguimientos mas granulares son altamente deseables en algunos escenarios ya que reduce los conflictos potenciales de datos (dos usuarios actualizando el mismo elemento en diferentes replicas). La desventaja es que incrementa la cantidad de información de seguimiento almacenada.

Otro concepto clave que necesitamos comentar es la noción de Knowledge. El Knowledge es una representación compacta de cambios de los cuales la réplica esta “enterada”. Cuando la información de la versión de actualiza, también lo hace el Knowledge para el almacén de datos. Los proveedores usan la réplica del Knowledge para:
1. Enumerar cambios (determina de cuales otros cambios la réplica no está “enterada”)
2. Detectar conflictos (determina cuales operaciones fueron hechas sin Knowledge de cada otra)
Cada replica también mantiene la información de tombstone para cada uno de los elementos que son eliminados. Esto es importante porque cuando la sincronización es ejecutada, si lo elementos no están allí, el proveedor no tendrá manera de decir que ese elemento ha sido eliminado y no podrá propagar el cambio a otros proveedores. Un tombstone debe tener la siguiente información:

• Global ID
• Versión de eliminación
• Versión de creación

Dado que el número de tombstones crecerá todo el tiempo, puede ser prudente crear un proceso para limpiar este almacén después de un periodo de tiempo a fin de ahorrar espacio. La información de soporte para administrar tombstone es provista con Sync Framework.

Metadatos

La réplica donde la sincronización es iniciada es llamada origen y la replica que se conecta es llamada destino. La siguiente sección muestra el flujo de sincronización descrito en el siguiente diagrama. Para una sincronización bidireccional, este proceso puede ser ejecutado dos veces; origen y destino se intercambian en la segunda iteración.

La sesión de sincronización iniciada con destino.
Durante esta fase, el proveedor origen inicializa la comunicación con el proveedor de destino. El enlace entre los dos proveedores es llamado sesión de sincronización.

Destino prepara y envía Knowledge
Como comentamos anteriormente, cada replica almacena su propio y único Knowledge. El Knowledge almacenado en el destino se transmite al origen.

El Knowledge destino es usado para determinar lo cambios a enviar
En el lado del origen, el Knowledge que fue recibido es comparado con el de la versión local para determinar qué elementos el destino no conoce. Es importante notar que las versiones que son enviadas no son los elementos actuales pero si un resumen de donde el último cambio fue hecho en cada elemento.

Cambio de versiones y envío de Knowledge origen al destino
Una vez que el origen ha preparado la lista de cambio de versiones requerida, son trasportados al destino (los elementos).

Versión local obtenida por cambio de elementos y comparada con la versión origen y Knowledge
El destino utiliza la versión para preparar una lista de elementos que el origen necesita para enviar. El destino también una esta información para detectar si hay alguna restricción o conflicto.

Los conflictos son detectados y resueltos o aplazados

Un conflicto es detectado cuando el cambio de versión en una réplica NO contiene el Knowledge de otro. Fundamentalmente, un conflicto ocurre si un cambio es hecho para el mismo elemento en dos replicas entre la sesión de sincronización.

Los conflictos específicamente ocurren cuando el Knowledge origen no contiene la versión destino para un elemento (implica que el Knowledge destino no contiene alguno de las versiones orígenes enviadas).

Si la versión es contenida en el Knowledge de destino entonces el cambio es considerado obsoleto.

Las replicas son libres de implementar una variedad de políticas para la resolución de los elementos en conflicto a través de la sincronización comunitaria. En seguida se muestran algunos ejemplos de políticas usadas para la resolución comunitaria.

• Origen gana: Los cambios hechos por la réplica local siempre ganan en un evento de conflictos.
• Destino gana: La réplica remota siempre gana.
• Replica especificada por ID siempre gana: No hay problema quien cambia un elemento, la replica con el ID designado siempre gana.
• Ultima escritura gana: Basado en asumir que todas las replicas tienen permiso para hacer cambios y los relojes están sincronizados, permite que el ultimo que escriba gana.
• Fundir (unir): En el evento de dos elementos duplicados en conflicto, se funde la información de uno con otro.
• Registra el conflicto: Elige simplemente el registro o aplaza el conflicto.

Petición de destino de datos del elemento del origen
Durante esta fase el destino ha determinado cuales elementos en el origen necesitan ser recuperados y comunicar esta petición al origen.

El origen prepara y envía datos del elemento
El origen toma la petición de los datos del elemento y prepara los datos actuales para ser transferidos al destino. Si el elemento al cual se le está dando el seguimiento es un registro de una base de datos, ese registro será enviado. Si el elemento es un archivo en una carpeta entonces el archivo será transferido.

Los elementos son aplicados al destino
Los elementos recibidos son tomados y aplicados al destino. Si hay algún error durante el proceso, tal como una falla de red, los elementos serán etiquetados como excepciones y corregidos durante la siguiente sincronización. El Knowledge recibido del origen es agregado al Knowledge de destino.

Ejemplo de sincronización.

Usando el flujo de sincronización descrito en una sección previa, mostraremos a través de un ejemplo de cómo Sync Framework enumeras los cambios y por último aplica los datos de los elementos.

En este ejemplo estarán dos replicas; Replica A y Replica B. La réplica A inicializara la sincronización para la réplica B (significa que la Replica A es el origen y Replica B es el destino).

Por ejemplo, imagine que queremos sincronizar archivos entre estas dos replicas. Un solo archivo en una carpeta puede ser el elemento al que queremos dar seguimiento y es descrito como In (por ejemplo I₁, I₂, I₃…). Cuando un nuevo archivo (I₁) es creado, los metadatos asociados con ese archivo también necesitan actualizar lo siguiente:

Si el archivo fuera actualizado nuevamente, la tabla podría verse así:

Es muy posible que múltiples archivos tengan seguimiento, así que vamos a ver estos múltiples elementos. Como puedes ver la información de la versión crece conforme más y más elementos son creados. Sync framework no requiere versiones previas de actualización para ser almacenada. Solo necesita el Knowledge de la versión más reciente de le actualización.

Si tomamos el estado actual de los elementos de esta réplica, representaríamos el Knowledge de la Replica A como:
Replica A Knowledge = A₅
A es el ID de la Replica y 5 es el conteo del tick actual que esta replica sabe que ha cambiado
En la réplica B, puede haber también un gran número de archivos. Esta replica se vería como la siguiente:

El Knowledge actual para la réplica actual es: Replica B Knowledge = B₄
En este punto elegiremos inicializar la sincronización entre las dos replicas. Replica A será el origen (la que iniciará la sincronización) y la Replica B será el destino.
Durante la sincronización el destino envía el Knowledge de origen. Como se menciono anteriormente, el Knowledge de las dos replicas se visualiza como:
Replica A Knowledge = A₅
Replica B Knowledge = A₄
El origen (Replica A) recibe este Knowledge y lo usa para determinar cual versión enviar al destino. Desde que la Replica B no está al corriente de cualquiera de los elementos en Replica A, el contenido entero de Replica A Es enviado. En éste caso, se incluirían las siguientes versiones.

El destino recibe estas versiones y las enumera a través de ello para determinar cuáles elementos son requeridos por el origen. También utiliza esta información para determinar si hay algún conflicto (por ejemplo, si el mismo archivo fue actualizado en ambas replicas).

Una vez completadas las peticiones de destino el origen envía los elementos de los cuales no tiene conocimiento. En este caso, Replica A enviará estos archivos asociados con I₁, I₂, e I₃.
El destino recibe estos archivos y los agrega a este folder.

Al terminar la sesión de sincronización, el proceso es ejecutado más de una vez, pero esta vez el origen establece como destino y el destino se establece como origen. Esto permite que Replica A reciba cualquiera de los archivos que fueron creados o cambiados en Replica B (I₁₀₄ y I₁₀₅)
El final de la sincronización ambas replicas tienen el seguimiento actualizado del Knowledge (“conocimiento”).

Replica A Knowledge = A₅, _B4
Replica A Knowledge = _A5, _B4

Ejemplo de conflicto

Extendiendo el ejemplo anterior, las dos replicas están actualmente sincronizados y cada una de las versiones de los elementos se apreciaría como lo siguiente:

Similarmente, el Knowledge para ambas replicas es como lo siguiente:
Replica A Knowledge = A₅, _B4
Replica A Knowledge = A₅, _B4
En este punto ambas replicas deciden actualizar el mismo archivo (elemento I2).
En la réplica A la versión del elemento de la tabla es actualizado para:

En la réplica B la versión del elemento de la tabla es actualizado para:

El Knowledge para ambas replicas es también actualizada como:
Replica A Knowledge = A₆, B₄
Replica B Knowledge = A₅, B₅
En este punto la réplica A inicializa la sincronización don la réplica B, Saltando a la siguiente fase donde el origen envía las versiones de los elementos y el Knowledge para el destino, los siguientes pasos son presentados para el elemento I₂.

1. La réplica B visualiza un nuevo cambio en el elemento para el elemento I₂ el cual es:

2. La réplica B revisa el Knowledge recibido de la Replica A (A₆, B₄) y determina que la Replica A no fue enterada del cambio hecho para el mismo elemento por Replica B.

1. Un conflicto es detectado y pasado a la aplicación o al proveedor para ser manipulado.

Resumen

Microsoft Sync Framework incluye todos las elementos para integrar aplicaciones en un ambiente desconectado o basado en red de colaboración, usando los proveedores pre-creados o escribiendo nuevos proveedores personalizado. Los proveedores permiten cualquier origen de datos para participar en la sincronización de datos sin tener en cuenta la red o el tipo de dispositivo.
Para más información u obtener una copia de Sync Framework SDK, visite http://msdn.microsoft.com/sync.

Material de apoyo
Tutorial básico paso a paso de Sync Framework
Ejemplo en codigo .net (descargable)
Proyectos para diversos escenarios con Sync Framework (Descargables)
Información general (español)
Cuestionario informativo Framework Sync (español)