Основные принципы построения пользовательских поставщиков

В платформу 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