Obtener acceso a los metadatos desde componentes con versiones diferentes
Metadata Storage Service almacena metadatos de réplica y del elemento en una base de datos ligera. Los metadatos se almacenan en un esquema de tabla específico y en formato binario, que podrían verse modificados según vayan saliendo versiones nuevas de Sync Framework. Además, los campos de proveedor personalizado en la base de datos podrían cambiar si un desarrollador publica versiones nuevas de un proveedor determinado. Para habilitar una mejor interoperabilidad entre las diferentes versiones, Sync Framework proporciona un formato de archivo canónico y la clase SyncMetadataStoreSerializer (para código administrado) o la interfaz ISyncMetadataStoreSerializer (para código no administrado), que ofrecen compatibilidad con versiones anteriores y posteriores para buena parte de los cambios de metadatos entre versiones.
Sync Framework también proporciona asistencia para actualizar el almacén de metadatos. Para obtener más información, vea Actualizar la versión del almacén de metadatos.
Usar el formato canónico para la compatibilidad entre versiones
Una de las ventajas fundamentales de un formato canónico es la capacidad de poder sincronizar réplicas de participantes parciales, como dispositivos, con versiones diferentes de un proveedor. Considere el ejemplo siguiente:
Una aplicación admite la sincronización entre un dispositivo y varios servidores en diversas oficinas corporativas. Los usuarios pueden sincronizar un dispositivo con un servidor, efectuar cambios en el dispositivo, sincronizar con un servidor en otra oficina, etc.
El proveedor de contactos de la compañía se ha publicado en tres versiones diferentes: 1.0, 2.0 y 2.5. La versión 1.0 se basa en Sync Framework 1.0 y las otras dos versiones en Sync Framework 2.0. Las tres versiones están aún disponibles y se admiten en la red corporativa.
Controlar versiones de Sync Framework
Si la aplicación almacena metadatos en un archivo binario de Metadata Storage Service en el dispositivo, es posible que el esquema y formato de los metadatos no sean compatibles con el proveedor con el que un usuario desee sincronizar. Esta incompatibilidad puede producirse bien porque el proveedor sea de una versión diferente y utilice un formato diferente de archivo de metadatos, o bien, porque el proveedor utilice una versión diferente de Sync Framework. Para evitar este problema, la aplicación podría utilizar en su lugar un archivo binario en cada servidor y, a continuación, serializar y deserializar los metadatos entre este archivo y un archivo canónico en cada dispositivo. El proceso es el siguiente:
Cuando se completa la primera sesión de sincronización para un dispositivo, la aplicación serializa metadatos para un archivo canónico en el dispositivo llamando a SerializeReplicaMetadata (para código administrado) o a ISyncMetadataStoreSerializer::SerializeReplicaMetadata (para código no administrado).
En cada una de las sesiones subsiguientes, la aplicación lleva a cabo las acciones siguientes:
Llama a DeserializeReplicaMetadata (para código administrado) o a ISyncMetadataStoreSerializer::DeserializeReplicaMetadata (para código no administrado) con el fin de deserializar los metadatos del archivo canónico y aplicarlos al archivo binario en el servidor.
Sincroniza los cambios entre el dispositivo y servidor.
Llama a SerializeReplicaMetadata (para código administrado) o a SerializeReplicaMetadata (para código no administrado) con el fin de serializar los metadatos actualizados de nuevo en el dispositivo.
Los procesos de serialización y deserialización son eficaces: para la serialización, se indizan las consultas que seleccionan metadatos en el almacén de Metadata Storage Service; para la deserialización, únicamente se deserializan los cambios incrementales del archivo canónico.
Controlar versiones del proveedor
La clase SyncMetadataStoreSerializer (para código administrado) y los métodos de la interfaz de ISyncMetadataStoreSerializer (para código no administrado) admiten el control de versiones del proveedor, para lo cual se serializa la versión del proveedor como si fuera parte de los metadatos y se comprueba la versión del proveedor esperada cuando se deserializan los metadatos. Considere el escenario siguiente:
Existen tres versiones de un proveedor (v1, v2 y v3).
En v2, se efectuó un cambio incompatible en el esquema personalizado para el proveedor.
v2 y v3 son compatibles.
Si serializa metadatos desde un proveedor v3, podría especificar un valor de v2 en los metadatos para la versión del proveedor. A continuación, un proveedor v2 o v3 puede deserializar los metadatos especificando un valor de v2 para el parámetro de la versión de compatibilidad del proveedor esperado. El proveedor v1 especificaría un valor de v1 y se produciría un error de diseño en la deserialización ya que los metadatos son incompatibles con v1. En general, utilice la versión más antigua posible para garantizar un nivel óptimo de compatibilidad con versiones anteriores del mismo proveedor.
Al publicar una versión nueva de un proveedor que actualice el esquema de metadatos, debe prestar atención a mantener la compatibilidad de los metadatos con las versiones anteriores del proveedor. Para obtener más información, vea Actualizar la versión del almacén de metadatos.