Введение в среду времени выполнения Microsoft Sync Framework

Корпорация Майкрософт
Ноябрь 2007 г.

Содержание
Введение
Участники
    Типы участников
Microsoft Synchronization Framework
    Основные компоненты
    Источник данных
    Метаданные
    Поток синхронизации
    Пример синхронизации
    Пример конфликта
Заключение

Введение

Microsoft Sync Framework – это всеобъемлющая платформа синхронизации, делающая возможными совместную работу и различные варианты автономной работы для приложений, служб и устройств. Платформа содержит технологии и средства, обеспечивающие перемещение, общий доступ и автономное получение данных. Платформа Microsoft Sync Framework предоставляет разработчикам возможность создания экосистем синхронизации для интеграции любых приложений с любыми типами данных из любых источников с использованием любого протокола и через любую сеть. 

Ключевым аспектом Microsoft Sync Framework является возможность создания собственных поставщиков синхронизации. Поставщик – это программный компонент, представляющий реплику для синхронизации. Реплика – это определенное хранилище данных для синхронизации, таких как файловая система на карманном устройстве. При представлении источника данных поставщик перечисляет изменения реплики. При представлении назначения поставщик вносит в реплику изменения. Если данные в источнике и назначении отличаются по типу или схеме, каждый поставщик выполняет необходимое сопоставление или преобразование. 

Microsoft Sync Framework включает ряд поставщиков, поддерживающих распространенные источники данных. Хотя для этих источников данных можно создать собственные поставщики, по возможности рекомендуется использовать предоставленные поставщики. Это может свести к минимуму время разработки и позволяет многократно использовать существующий протестированный код. Включены следующие поставщики.

• Службы синхронизации для ADO.NET: синхронизация для источников данных с поддержкой ADO.NET
• Службы синхронизации для файловых систем: синхронизация для файлов и папок
• Службы синхронизации для SSE: синхронизация для расширений Simple Sharing Extensions (SSE), например каналы RSS и ATOM

Разработчики могут использовать все предоставленные поставщики или создать собственные поставщики для обмена данными между устройствами и приложениями.

Целью оставшейся части данного документа является объяснение того, как платформа Microsoft Sync Framework обеспечивает синхронизацию для создания топологии синхронизации. Будут рассмотрены некоторые ключевые концепции поставщиков синхронизации, помогающие понять процесс создания поставщика. Более подробные сведения о Microsoft Sync Framework приведены на веб-узле https://msdn2.microsoft.com/en-us/sync/default.aspx.

Участники

Перед рассмотрением отдельных компонентов поставщика следует познакомиться с поддерживаемыми Microsoft Sync Framework различными типами участников синхронизации. Участник – это сочетание поставщика и соответствующей реплики. Реплика для синхронизации, являющаяся хранилищем данных, может быть чем угодно, от веб-службы до портативного компьютера или съемного накопителя для порта USB. 

Типы участников

Платформа Microsoft Sync Framework поддерживает три типа участников: полноправные, частичные и простые. Тип участника определяется возможностью хранения и обработки метаданных синхронизации. По крайней мере, будем считать, что реплика способна программно возвращать запрашиваемые данные. В конечном счете, необходимо определить, может ли реплика обеспечивать следующие возможности.

1. Сохранение и управление данными на существующем устройстве или в текущем хранилище данных.
2. Запуск приложений (в нашем случае служба синхронизации) непосредственно с устройства

Важно различать типы участников, которые будут являться частью экосистемы синхронизации. Это позволяет определить возможность сохранения сведений о состоянии, необходимых для поставщика, а также возможность запуска поставщика непосредственно с устройства. В конечном счете, модель участников должна быть типовой. Поэтому полноправный участник может быть настроен в качестве частичного или простого участника. 

Полноправные участники

Полноправные участники – это устройства, позволяющие разработчикам создавать приложения и новые хранилища данных непосредственно на устройстве. Примерами полноправных участников являются портативные компьютеры и смартфоны, поскольку новые приложения могут быть выполнены непосредственно на устройстве. Также возможно создание новых хранилищ для сохранения данных в случае необходимости.

Частичные участники

Частичные участники – это устройства с возможностью сохранения данных на устройстве.  Однако запуск исполняемых файлов непосредственно с этих устройств невозможен. Важным фактом о частичных участниках является возможность сохранения необходимых для синхронизации метаданных и синхронизации с любыми полноправными участниками. Одним из примеров частичных участников является съемный накопитель. Эти устройства действуют так же, как и жесткие диски с возможностью создания, обновления и удаления данных. Однако обычно они не предоставляют интерфейс, позволяющий выполнять приложения непосредственно на них. 

Простые участники

Простые участники – это устройства только с возможностью предоставления запрашиваемой информации.  На этих устройствах невозможно сохранение и управление новыми данными, а также создание новых приложений. Простой участник полагается на полноправного участника для сохранения его метаданных (и поэтому возможна только синхронизация с этим полноправным участником).

Примерами простых участников являются каналы RSS и веб-службы, предоставленные сторонними организациями, например Amazon и EBay. Эти организации могут предоставлять возможность выполнения веб-служб и получения результатов, но они не позволяют создавать собственные хранилища данных или выполнять собственные приложения на их веб-серверах. 

Теперь всё вместе

Итоговой целью Microsoft Sync Framework является возможность интеграции любых источников данных независимо от типа участника. По этой причине простые и частичные участники могут синхронизировать данные с полноправными участниками. Необходим только один полноправный участник с возможностью сохранения информации и запуска процесса синхронизации.

Microsoft Synchronization Framework

Основные компоненты

Перед реализацией синхронизации с помощью Microsoft Sync Framework сначала необходимо ознакомиться с основными компонентами поставщика синхронизации. Эти концепции будут подробно рассмотрены в примерах синхронизации далее в этом документе.

На следующей схеме показана связь поставщика с источником данных и получение сведений о состоянии из хранилища метаданных. Эти поставщики, в свою очередь, взаимодействуют с другими поставщиками через сеанс синхронизации.

Источник данных

Источник данных – это местоположение сохранения всех данных для синхронизации. Источник данных может быть реляционной базой данных, файловой системой, веб-службой или даже нестандартным источником данных, включенным в бизнес-приложение. Участие данных в синхронизации зависит от возможности программного доступа к данным.

Метаданные

Фундаментальным аспектом поставщика является возможность сохранения сведений о хранилище данных и объектах в этом хранилище с учетом сведений о состоянии и изменениях. Метаданные могут быть сохранены в любом месте, будь то файл, база данных или существующее хранилище данных реплики.  Для удобства Microsoft Sync Framework предоставляет полную реализацию хранилища метаданных, созданного на основе SQL Server Compact Edition. Это хранилище не является обязательным, но его использование означает, что не нужно беспокоиться о сохранении метаданных синхронизации. 

Метаданные для хранилища данных могут быть разделены на три основных компонента.

• Версии. Небольшое количество данных, сохраненных для каждого синхронизируемого элемента, называется версиями элементов. Эти данные содержат сведения о месте и времени изменения элемента, а также соответствующий идентификатор элемента. Для базы данных элемент может быть всей строкой в таблице. Или же элемент может быть столбцом строки таблицы.

  При изменении элемента данные, сохраненные для этого изменения, будут включать в себя версию создания и версию обновления. Эти версии состоят из двух компонентов: счетчика отсчетов, являющегося логическими часами, используемыми во всем источнике для уникальной идентификации изменения, и идентификатора реплики, который используется для уникальной идентификации хранилища данных, в котором были внесены изменения. При создании элемента версия создания совпадает с версией обновления. При последующих обновлениях элемента изменяется только версия обновления. 

  Все отслеживание изменений должно происходить по крайней мере на уровне элементов. Другими словами, каждый элемент должен иметь независимую версию.   В некоторых ситуациях крайне желательно более детальное отслеживание, поскольку снижается возможность конфликтов данных (обновление двумя пользователями одного элемента в разных репликах). Недостатком является увеличение количества сохраняемых сведений об отслеживании изменений.

  Существует два основных способа реализации управления версиями.

  1. Встроенное отслеживание. При использовании этого способа сведения об отслеживании изменений для элемента обновляются при внесении изменений. Например, в случае базы данных может использоваться триггер для обновления таблицы отслеживания изменений сразу же после обновления строки.
  2. Асинхронное отслеживание. Этот способ основан на внешнем процессе, который запускается и выполняет поиск изменений. Все найденные обновления добавляются в информацию о версии. Это может быть частью запланированного процесса или может выполняться до синхронизации. Обычно этот процесс используется при отсутствии внутренних механизмов для автоматического обновления информации о версии при обновлении элементов (например, невозможно включить логику в конвейер обновления). Общим способом проверки изменений является сохранение состояния элемента и его сравнение с текущим состоянием. Например, может выполняться проверка изменения времени последней записи или размера файла после последней синхронизации.

• Знания. Знания – это компактное представление известных реплике изменений данных. Целью знаний является повышение эффективности синхронизации, поскольку это позволяет ограничить количество информации, передаваемой между репликами. При обновлении информации о версии так же обновляются знания для хранилища данных. Поставщики используют знания реплики для выполнения следующего.

  1. Перечисление изменений. Определение изменений, не известных другой реплике.
  2. Определение конфликтов. Определение операций, выполненных без наличия сведения о других выполняемых операциях.

• Захоронения. Каждая реплика также должна поддерживать информацию захоронения для всех удаляемых элементов. При отсутствии отслеживания операций удаления поставщик не может сообщать об удалении элемента (например, файла). В этом случае поставщик не может распространять информацию об изменениях версий другим поставщикам. Захоронение должно содержать следующую информацию.

  • **Глобальный идентификатор.  **Идентификатор реплики и счетчик отсчетов, используемые для уникальной идентификации элемента захоронения во всех репликах.
  • Версия удаления. Версия обновления, связанная с элементом захоронения.
  • Версия создания. Идентификатор реплики и счетчик отсчетов, соответствующий моменту изначального создания элемента.

  Поскольку объем данных в журнале захоронения со временем увеличивается, по истечении определенного периода времени рекомендуется создать процесс для очистки этого хранилища. Очистка данных хранилища экономит место и позволяет повысить производительность синхронизации. Платформа Microsoft Sync Framework поддерживает управление данными захоронения.

Поток синхронизации

Реплика, где синхронизация инициируется, называется источником, а реплика, к которой синхронизация подключается, называется назначением. В следующих разделах данной статьи описывается поток синхронизации, показанный на следующей схеме. Для двунаправленной синхронизации процесс выполняется дважды, с заменой источника и назначения при второй итерации.

Сеанс синхронизации, инициированный с назначением

На этом этапе устанавливается сеанс синхронизации, в котором создается связь источника с поставщиком.

Подготовка и отправка знаний назначением

Как обсуждалось ранее, каждая реплика сохраняет свои собственные знания. Сохраненные в месте назначения знания передаются источнику.

Знания назначения используются для определения изменений для отправки

Полученные на стороне источника знания сравниваются с локальными версиями элементов для определения элементов, неизвестных назначению. Важно отметить, что отправляемые версии являются не самими элементами, а сводкой последних изменений всех элементов. 

Версии изменений и знания источника, отправленные в место назначения

После подготовки в источнике необходимого списка версий изменений они передаются в место назначения

Локальная версия, полученная для измененных элементов и сравненная с версией и базой знаний источника

Версии используются в месте назначения для подготовки списка элементов, необходимых для отправки источником. Эти сведения также используются в месте назначения для определения наличия конфликтов ограничений. Конфликты ограничений – это конфликты, нарушающие установленные для элементов ограничения, такие как связь между папками и расположение одинаково названных данных в файловой системе.

Конфликты определяются и разрешаются или откладываются

По существу, конфликт возникает при изменении одного элемента на двух репликах между синхронизациями. В среде выполнения Microsoft Sync Framework конфликт определяется, если версия изменения в одной реплике НЕ содержит сведения об изменении другой реплики.   Более подробный пример выполнения процесса определения рассматривается далее в разделе «Пример конфликта».

Реплики могут реализовывать различные политики для разрешения противоречащих элементов в топологии синхронизации. Ниже приведены некоторые примеры наиболее часто используемых политик разрешения.

• Приоритет источника. Изменения, выполненные исходной репликой, при обнаружении конфликта всегда имеют приоритет.
• Приоритет назначения. Изменения, выполненные репликой назначения, всегда имеют приоритет
• Объединение. Объединение двух изменений. Итоговые суммы инвентаризации являются примерами необходимости объединения (суммирования) значений двух реплик вместо выбора одного значения в качестве верного.
• Регистрация конфликта. Регистрация или откладывание конфликта.

Назначение запрашивает данные элемента из источника

На этом этапе в месте назначения определяются необходимые для получения элементы источника; этот запрос пересылается источнику.

Подготовка и отправка данных элементов источником

Источник получает запрос данных элемента и подготавливает передачу в место назначения реальных данных. Если отслеживаемый элемент является строкой базы данных, будет отправлена эта строка. Если элемент является файлом в папке, будет передан файл.

Элементы применяются в месте назначения

Полученные данные применяются в месте назначения. При возникновении во время выполнения этого процесса ошибок, например ошибки сети, элементы будут помечены как исключения и исправлены при следующей синхронизации. Сведения, полученные из источника, добавляются в знания назначения.

Пример синхронизации

Используя поток синхронизации, описанный в предыдущем разделе, мы рассмотрим пример синхронизации файлов, демонстрирующий перечисление изменений и итоговое применение данных источника платформой Microsoft Sync Framework. В этом примере используются две реплики: реплика A и реплика B. Реплика A инициирует синхронизацию с репликой B (то есть реплика A является источником, а реплика B – назначением). Предположим, необходимо синхронизировать файлы этих двух реплик. Отслеживаемый элемент является одним файлом в папке; он описывается как I_n (например, I_1, I_2, I_3…).  При создании нового файла (I₁) связанные с этим файлом метаданные должны быть обновлены следующим образом.

При повторном обновлении этого файла таблица версий может выглядеть следующим образом.

В приведенном выше примере для счетчика отсчетов обновления установлено значение 5, поскольку логические часы для счетчика отсчетов используются во всем источнике. Это означает, что счетчики отсчетов со значениями 2-4 используются для изменений других элементов реплики. 

Например, на следующей схеме указаны два дополнительных элемента I₂ и I₃ в отслеживаемой реплике. Как можно заметить, объем информации о версии увеличивается по мере создания все большего количества элементов. Microsoft Sync Framework не требует сохранения предыдущих версий обновления. Должна быть известна только самая последняя версия обновления.

Если взять текущее состояние элементов для этой реплики, знания реплики A будут представлена следующим образом.

Знания реплики A = A₅

Как упоминалось ранее, знания – это компактное представление известных реплике изменений данных. В данном случае A – это уникальный идентификатор, назначенный этой реплике, а 5 – текущее значение счетчика отсчетов, определяющее число известных реплике изменений. Если эта реплика была синхронизирована с какими-либо иными репликами, эти сведения также будут указаны в данном списке.

В реплике B также может содержаться ряд файлов. Эта реплика выглядит следующим образом.

Реплика B

Текущие знания реплики B:

знания реплики B = B₄

В данный момент мы решили инициировать синхронизацию между двумя репликами. Реплика A будет источником (реплика, инициирующая синхронизацию), а реплика B – назначением.

Во время синхронизации знания назначения передаются источнику.  Как указывалось ранее, знания для двух реплик выглядят следующим образом.

Знания реплики A = A₅

Знания реплики B = B₄

Источник (реплика A) получает эти знания и использует их для определения версий для отправки назначению. Поскольку у реплики B отсутствуют сведения об элементах реплики A, отправляется все содержимое. В данном случае реплика A будет включать в себя следующие версии.

Пакет версий реплики A

Назначение получает эти версии и перечисляет их для определения элементов, которые должны быть запрошены у источника. Эта информация также используется для определения наличия конфликтов (например, один файл был обновлен на обеих репликах). 

После выполнения этих действий назначение отправляет источнику запрос на передачу элементов, неизвестных назначению. В данном случае A отправит файлы, соответствующие элементам I_1, I₂ и  I_3.

Назначение получает эти файлы и добавляет их в свою папку. Элементы реплики B теперь будут включать элементы, полученные от реплики A.

Реплика B – обновленные таблицы элементов

По завершении этой синхронизации процесс выполняется еще раз, источник становится назначением, а назначение – источником. Это позволяет реплике A получить файлы, созданные или измененные на реплике (I₁₀₄ и  I₁₀₅).

По завершении синхронизации обе реплики будут иметь следующие обновленные знания.

Знания реплики A = A_5, B₄

Знания реплики B = A_5, B₄

Пример конфликта

Продолжаем предыдущий пример. Теперь две реплики синхронизированы и имеют следующие версии элементов.

Аналогично, знания для обеих реплик выглядят следующим образом.

Знания реплики A = A_5, B₄

Знания реплики B = A_5, B₄

В данный момент на обеих репликах будет выполнено обновление одного и того же файла (элемент I_4).

Обновленная таблица версий элементов реплики A будет выглядеть следующим образом.

Обновленная таблица версий элементов реплики B будет выглядеть следующим образом.

Знания для обеих реплик также обновляются и выглядят следующим образом.

Знания реплики A = A_6, B₄

Знания реплики B = A_5, B₅

В данный момент реплика A инициирует синхронизацию с репликой B. Перейдем к этапу отправки источником версий элементов и знаний назначению; выполняются следующие действия для элемента I₂.

1. Реплика B обнаруживает новое изменение для элемента I₂, который приведен ниже.

   Счетчик отсчетов обновления	Идентификатор реплики обновления
   6	A

2. Реплика B проверяет знания, полученные от реплики A (A6, B4), и определяет, что реплике A не было известно о том, что этот элемент был изменен репликой B.

   Счетчик отсчетов обновления	Идентификатор реплики обновления
   5	B

3. Определяется конфликт, который передается приложению или поставщику для разрешения.

Как указывалось ранее, приложение может выбрать способ разрешения конфликта или отложить его разрешение. При откладывании конфликта он будет постоянно происходить при выполнении последующих синхронизаций до его разрешения. После разрешения конфликта при следующей синхронизации исходная реплика получит обновленное значение.

Заключение

Платформа Microsoft Sync Framework содержит все необходимое для интеграции приложений в автономную сеть или сеть на основе совместной работы, с помощью предварительно созданных поставщиков или создания собственных поставщиков. Поставщики позволяют любым источникам данных участвовать в синхронизации данных независимо от типа сети или устройства.

В данной статье рассмотрены основные компоненты Microsoft Sync Framework. Также были рассмотрены примеры, демонстрирующие использование в Microsoft Sync Framework знаний для обеспечения эффективного обмена данными любыми хранилищами данных. Наконец, мы увидели, как Microsoft Sync Framework обеспечивает обнаружение конфликтов и позволяет приложениям или поставщикам эффективно разрешать конфликты с помощью различных механизмов.

Используя эту платформу, мы создаем основу для синхронизации, которая может использоваться для любых устройств в любых хранилищах данных с помощью любой топологии сети. Можно просто интегрировать различные источники данных для создания одноранговой сети и даже расширить хранилища данных, если изменения схем невозможны. 

В конечном счете, Microsoft Sync Framework предоставляет платформу с большими возможностями встраивания и масштабирования для обеспечения синхронизации.

Для получения дополнительных сведений или копии Microsoft Sync Framework CTP1 SDK посетите веб-узел https://msdn2.microsoft.com/en-us/sync/default.aspx.