Доступ к метаданным из компонентов с различными версиями
Службы хранилища метаданных сохраняют метаданные реплик и элементов в упрощенной базе данных. Метаданные сохраняются в конкретной схеме таблицы и в двоичном формате, которые могут измениться в следующих выпусках платформы Sync Framework. Кроме того, поля пользовательского поставщика в базе данных могут измениться в следующих версиях данного поставщика. Чтобы обеспечить большую совместимость между разными версиями, платформа Sync Framework предусматривает канонический формат файла и класс SyncMetadataStoreSerializer (для управляемого кода) или интерфейс ISyncMetadataStoreSerializer (для неуправляемого кода), которые обладают прямой и обратной совместимостью для достаточно большого числа изменений версий метаданных.
Sync Framework также обеспечивает поддержку обновления хранилища метаданных. Дополнительные сведения см. в разделе Обновление версии хранилища метаданных.
Использование канонического формата для обеспечения совместимости версий
Одним из ключевых преимуществ канонического формата является возможность производить синхронизацию реплик частичных участников (например, устройств) с разными версиями поставщиков. Рассмотрим следующий пример:
Приложение поддерживает синхронизацию между устройством и рядом серверов в различных корпоративных филиалах. Пользователи могут синхронизировать устройство с сервером, вносить изменения на устройстве, выполнять синхронизацию с сервером в другом филиале и т. д.
Поставщик контактов компании был выпущен в трех версиях: 1.0, 2.0 и 2.5. Версия 1.0 построена на основе платформы Sync Framework 1.0, а остальные две версии — на основе платформы Sync Framework 2.0. Все три версии до сих пор доступны и поддерживаются в корпоративной сети.
Управление версиями Sync Framework
Если приложение хранит метаданные в двоичном файле службы хранилища метаданных на устройстве, то их схема и формат могут оказаться несовместимыми с поставщиком, через который пользователь пытается выполнить синхронизацию. Причиной этого может послужить другая версия поставщика, другой формат файла метаданных либо использование поставщиком другой версии платформы Sync Framework. Чтобы избежать появления этой проблемы, приложение может использовать на сервере двоичный файл, а для всех устройств производить сериализацию и десериализацию метаданных через канонический файл. Применяется следующая обработка.
После завершения первого сеанса синхронизации приложение сериализует метаданные в канонический файл на устройстве вызовом метода SerializeReplicaMetadata (для управляемого кода) или интерфейса ISyncMetadataStoreSerializer::SerializeReplicaMetadata (для неуправляемого кода).
Во время каждого последующего сеанса приложение выполняет следующие действия.
Вызывает метод DeserializeReplicaMetadata (для управляемого кода) или интерфейс ISyncMetadataStoreSerializer::DeserializeReplicaMetadata (для неуправляемого кода), чтобы выполнить десериализацию метаданных из канонического файла и сохранить их в двоичном файле на сервере.
Синхронизирует изменения между устройством и сервером.
Вызывает метод SerializeReplicaMetadata (для управляемого кода) или SerializeReplicaMetadata (для неуправляемого кода), чтобы сериализовать обновленные метаданные обратно на устройство.
Сериализация и десериализация являются эффективными процессами, поскольку для сериализации запросы выборки метаданных из службы хранилища метаданных индексируются, а при десериализации десериализуются только добавочные изменения в каноническом файле.
Управление версиями поставщика
Класс SyncMetadataStoreSerializer (для управляемого кода) и методы интерфейса ISyncMetadataStoreSerializer (для неуправляемого кода) поддерживают управление версиями поставщика, включая версию поставщика при сериализации метаданных и сверяя ее с ожидаемой версией поставщика по время их десериализации. Рассмотрим следующий сценарий.
Существует три версии поставщика (v1, v2 и v3).
В версии v2 в пользовательской схеме поставщика сделано несовместимое изменение.
Версии v2 и v3 несовместимы между собой.
При сериализации метаданных от поставщика версии v3 можно указать значение v2 для версии поставщика в метаданных. Поставщик версии v2 или v3 может десериализовать метаданные, указав значение v2 для параметра ожидаемой версии поставщика. Если поставщик версии v1 указал значение v1, то десериализация завершится неуспешно по определению, поскольку метаданные несовместимы с версией v1. Чтобы обеспечить наивысший уровень совместимости с предыдущими версиями поставщика, следует пользоваться наименьшей возможной версией.
При выпуске новой версии поставщика, в которой обновляется схема метаданных, необходимо обеспечить совместимость метаданных с предыдущими версиями поставщика. Дополнительные сведения см. в разделе Обновление версии хранилища метаданных.