Основные принципы построения пользовательских поставщиков
В платформу Microsoft Sync Framework входят поставщики для нескольких сценариев синхронизации, например для синхронизации файлов, однако в некоторых случаях необходим пользовательский поставщик. Для создания пользовательских поставщиков разработчику придется написать больше кода, чем для поставщиков, входящих в Sync Framework, однако пользовательские поставщики являются ключевым компонентом для обеспечения гибкости и расширяемости платформы Sync Framework. В этом разделе приводятся основные сведения о пользовательских поставщиках, которые помогут выбрать тип пользовательского поставщика в соответствии с задачами приложения. Читателям, впервые приступающим к работе с Sync Framework, рекомендуется ознакомиться с подразделом «Компоненты Sync Framework» раздела Выбор соответствующих компонентов Sync Framework.
Основные сведения о поставщиках, приложениях и управлении метаданными
Платформа Microsoft Sync Framework синхронизирует реплики, используя четыре основных компонента: среду выполнения синхронизации, сеанс синхронизации и две службы синхронизации. Для синхронизации данных приложение создает сеанс синхронизации и передает ему поставщик источника и поставщик назначения. Сеанс использует поставщик источника, чтобы получить новые изменения, произошедшие в реплике источника, а поставщик назначения — чтобы применить эти изменения к реплике назначения. Поставщик организует хранение метаданных, в том числе набора знаний, для каждой реплики и для каждого синхронизируемого элемента. Набор знаний — это метаданные, которые описывают все изменения, примененные к реплике, как непосредственно, так и в ходе синхронизации.
Если Sync Framework не предоставляет поставщик для синхронизируемого хранилища данных, необходимо создать пользовательский поставщик. В Sync Framework входят управляемые и неуправляемые API-интерфейсы для двух типов пользовательских поставщиков: простых и стандартных.
Простые поставщики имеют меньшее число и низкую сложность интерфейсов, что позволяет ускорить разработку и более очевидным образом реализовать поддержку для хранилищ данных, в которых не применяются сложные механизмы отслеживания изменений.
Стандартные поставщики обладают максимальной гибкостью и обеспечивают самую высокую производительность и надежность.
Поставщики обоих типов могут применяться для синхронизации широкого спектра хранилищ данных и поддерживают работу в различных важных областях — фильтрации, обработке конфликтов и др. Однако между поставщиками существуют важные различия. Дополнительные сведения см. в подразделе «Выбор между простым и стандартным поставщиками» далее.
На следующем рисунке показаны основные элементы, используемые в сценарии синхронизации. Этот рисунок аналогичен рисунку, приведенному в разделе Выбор соответствующих компонентов Sync Framework, однако сопровождающий текст предоставляет дополнительные сведения относительно пользовательских поставщиков и демонстрирует поток данных и метаданных в системе.
Элементы на иллюстрации имеют один из трех типов.
Элементы, создаваемые разработчиком.
Приложение запускает синхронизацию, отвечает на события и выполняет другие задачи в зависимости от требований приложения. Дополнительные сведения см. в разделе Реализация приложения синхронизации.
Поставщик управляет метаданными для реплики и работает с платформой Sync Framework для перечисления изменений и обнаружения конфликтов. Поставщик также работает с хранилищем данных реплики, отправляя данные элементов, когда поставщик выступает в качестве поставщика источника, и применяя изменения, когда поставщик выполняет роль поставщика назначения. Поставщик определяется типом синхронизируемых данных. Два поставщика в сеансе часто имеют один тип, однако это необязательно. Дополнительные сведения о совместимости см. в разделе Объединение данных от различных поставщиков.
Управляемый код: в простом поставщике реализуется класс FullEnumerationSimpleSyncProvider или AnchorEnumerationSimpleSyncProvider. В стандартном поставщике реализуются классы KnowledgeSyncProvider, IChangeDataRetriever и INotifyingChangeApplierTarget.
Неуправляемый код: в простом поставщике реализуются интерфейс IFullEnumerationSyncProvider или IAnchorSyncProvider. В стандартном поставщике реализуются интерфейсы IKnowledgeSyncProvider, ISyncProvider, ISynchronousDataRetriever или ISynchronousNotifyingChangeApplierTarget (или асинхронные версии интерфейсов для асинхронных поставщиков).
Хранилищем данных может быть любое хранилище, для которого будет создан поставщик.
Протокол передачи данных определяет способ передачи изменений данных между двумя поставщиками.
Элементы, предоставляемые платформами Sync Framework.
В зависимости от типа используемого кода (управляемого или неуправляемого) приложение обменивается данными с модулем взаимодействия синхронизации (SyncOrchestrator) или сеансом синхронизации (ISyncSession). Затем модуль или сеанс связывается с каждой службой синхронизации и передает клиентскому приложению сведения о состоянии, конфликтах и ошибках.
Среда выполнения синхронизации содействует поставщикам в выполнении распространенных задач синхронизации — управление метаданными, обнаружение конфликтов и применение изменений.
Элементы, создаваемые разработчиком или предоставляемые платформой Sync Framework в зависимости от требований приложения и поставщика.
Хранилище метаданных содержит метаданные, которые платформа Sync Framework использует для определения того, какие изменения должен выбрать каждый из поставщиков для применения к обслуживаемому им хранилищу данных. Хранилище метаданных может отделяться от хранилища данных (располагаться в отдельном файле или отдельной базе данных) или интегрироваться в хранилище данных (располагаться в дополнительной таблице базы данных). Обычно служба синхронизации управляет метаданными, необходимыми для синхронизации. Однако в зависимости от реализации реплики может оказаться более эффективным выполнять часть задач по управлению метаданными в отдельном компоненте, например в службе, которая очищает старые метаданные по расписанию, а не во время синхронизации. Необходимые метаданные и способы их хранения и работы с ними зависят от используемого поставщика. Сведения о требованиях к метаданным для каждого типа поставщика см. в разделах Управление метаданными для простых поставщиков и Требования к метаданным для стандартных поставщиков.
Простой поставщик берет на себя почти все операции по взаимодействию с хранилищем метаданных. Он пользуется реализацией службы хранилища метаданных, которая входит в платформу Sync Framework. Стандартные пользовательские поставщик могут использовать эту реализацию, другую реализацию, основанную на API-интерфейсе службы хранилища метаданных, или полностью пользовательскую реализацию, которая хранит метаданные в отдельном хранилище или в пределах хранилища данных. Дополнительные сведения см. в разделе Управление метаданными для стандартных поставщиков.
Выбор между простым и стандартным поставщиками
В большинстве случаев рекомендуется использовать простой поставщик, однако сначала следует изучить предположения, сделанные в ходе разработки API-интерфейса для простого поставщика.
Синхронизируемые хранилища данных не поддерживают ни один тип отслеживания изменений или поддерживают только отслеживание изменений на основе точек привязки.
Точка привязки — это объект, который показывает, какие элементы в хранилище данных изменились со времени последнего сеанса синхронизации. В хранилищах, где не поддерживается отслеживание изменений или ведется только отслеживания на основе точек привязки, набор знаний синхронизации обновляется только в ходе сеанса синхронизации (асинхронно), а не в момент, когда изменение выполняется в хранилище (синхронно). Это может снизить производительность, если в какой-либо реплике параллельно выполняются несколько сеансов синхронизации. Поэтому если для приложения необходим высокий уровень параллелизма, а каждое хранилище данных поддерживает синхронное обновления набора знаний синхронизации, следует использовать стандартный поставщик.
В реплике необходимо синхронизировать элементы только одного типа.
В силу ограничений хранилища данных или требований приложения метаданные необходимо хранить вне хранилища данных.
Простые поставщики обеспечивают хранение метаданных с помощью службы хранилища метаданных, реализованной в Sync Framework. Метаданные хранятся отдельно от данных, которые они описывают, что потенциально может вызвать две проблемы.
В случае удаленного хранения метаданных они могут оказаться полностью недоступны в ходе сеанса синхронизации. Например, если доступно сетевое подключение между двумя синхронизируемыми репликами, но недоступно соединение с сервером, где размещаются метаданные.
Не гарантируется согласованность транзакций между данными и метаданными. Рекомендуется хранить метаданные на одном компьютере с данными, однако поддержка транзакций доступна только в случае, когда используется стандартный поставщик, а метаданные хранятся в хранилище данных (или для обновления обоих хранилищ используется распределенная транзакция). Учтите, что стандартные поставщики также могут использовать службу хранилища метаданных, однако, в отличие от простых поставщиков, это не является обязательным.
Если требования приложения согласуются с этими предположениями, рекомендуется использовать простые поставщики. Дополнительные сведения о простых поставщиках см. в разделе Реализация простого пользовательского поставщика. Дополнительные сведения о стандартных поставщиках см. в разделе Реализация стандартного пользовательского поставщика.
Основные сведения о типах участников Sync Framework
Sync Framework может использоваться для синхронизации данных между участниками с различной функциональностью. Участником является устройство или служба, которая может синхронизироваться с другими системами, на которых выполняется Sync Framework.
Sync Framework поддерживает следующие типы участников:
полный участник;
участник-посредник;
частичный участник;
простой участник.
Полный участник
Полный участник локально размещает среду выполнения и хранит метаданные. Он может принять участие в сценариях одноранговой синхронизации, поскольку ее могут начинать оба участника.
Два полных участника в одноранговой синхронизации
Частичный участник
Частичный участник хранит синхронизируемые метаданные, но не может их обрабатывать. Частичный участник зависит от нескольких полных участников, на которых размещается среда выполнения и начинается синхронизация. Потоки данных могут проходить через этих участников, поскольку участники хранят метаданные для синхронизации с несколькими главными участниками и передают эти метаданные всем другим полным участникам. Частичные участники не могут принимать участие в одноранговых сценариях из-за неспособности обрабатывать метаданные и размещать среду выполнения. Примерами частичных участников являются флэш-накопители USB и мобильные телефоны, способные сохранять данные.
На следующем рисунке показан полный участник, такой как компьютер, синхронизирующийся с частичным участником, например с мобильным телефоном. Полный участник перечисляет или фильтрует изменения от имени частичного участника и сохраняет на нем метаданные. Это позволяет любому другому полному участнику синхронизировать этот частичный участник.
Синхронизация полного участника с частичным участником
Простой участник
Простой участник не хранит метаданные, не может размещать среду выполнения и может не проводить отслеживания изменений. Все действия — перечисление и применение изменений, управление метаданными и их хранение — за него выполняет полный участник. Поскольку простой участник не может хранить метаданные, он действует только как конечный узел для полного участника, который передает данные и принимает их от других участников.
На следующем рисунке показан полный участник, использующий службу хранилища метаданных для сохранения метаданных простого участника и задействующий от его имени все аспекты синхронизации. Хранилище метаданных используется для отслеживания изменений, связанных с простым участником, но хранится на полном участнике из-за ограниченных возможностей простого участника.
Полный участник, использующий службу хранилища метаданных для синхронизации простого участника
Участник-посредник
Участник-посредник начинает синхронизацию для удаленного поставщика, локально обрабатывая вызовы и отправляя их удаленному поставщику, например базе данных, хранящейся на сервере.
Безопасность Примечание. |
---|
Sync Framework не обеспечивает проверку подлинности и шифрование связи между поставщиком учетной записи-посредника и удаленным поставщиком. Чтобы предотвратить несанкционированный доступ и изменение данных, необходимо защитить канал связи между поставщиком учетной записи-посредника и удаленным поставщиком с помощью подходящего механизма взаимной проверки подлинности и шифрования, например протокола SSL. |
На следующем рисунке показана синхронизация поставщика полного участника с поставщиком учетной записи-посредника. Обратите внимание, что поставщик участника-посредника просто отправляет команды и метаданные по сети удаленному поставщику. Удаленный поставщик расположен на сервере базы данных и применяет фактическую логику синхронизации. Красная пунктирная линия показывает границу компьютера.
Синхронизация полного участника с участником-посредником
На следующем рисунке показано, как Sync Framework может использоваться для синхронизации поставщиков, которые являются удаленными по отношению к приложению, начинающему синхронизацию. Управляющее приложение может соединять две веб-службы или два синхронизирующихся интеллектуальных устройства. Обратите внимание, что оба локальных поставщика являются удаленными по отношению к удаленным поставщикам. Красные пунктирные линии показывают границы компьютеров.
Центральное приложение синхронизирует двух участников-посредников
См. также
Основные положения
Выбор соответствующих компонентов Sync Framework
Реализация простого пользовательского поставщика
Реализация стандартного пользовательского поставщика
Реализация приложения синхронизации
Образцы Sync Framework