Microsoft Sync Framework basics 2: Microsoft Sync Framework architecture and Runtime

Document directory

• Sync Framework Participants)
• Sync Framework Core Components
• Sync Framework system architecture

Microsoft Sync Framework architecture and Runtime

This article will first introduce various synchronization participants. The types of participants determine whether metadata can be stored and whether the synchronization process can be started directly. We will discuss the Core Components and system architecture of Microsoft Sync Framework in detail to give you a global understanding of the Sync Framework.

 

Sync Framework Participants)

Before discussing the core components of the Sync Framework, we need to first understand the different types of synchronization participants supported by the Sync Framework. A participant is a combination of the provider and its associated copies, representing the synchronization end. The copy to be synchronized (that is, the information warehouse) can be taken from Web Services, laptops, and even any objects in the U disk.

Microsoft Sync Framework supports three types of participants: complete, partial, and simple. The types of participants are determined by their ability to store and process synchronized metadata. At least, we can assume that if there is a request, the copy can return information through the program. Finally, you need to determine whether the copy can:

1. Store and operate information on existing devices or data storage, and
2. Allow applications (called synchronous providers) to run directly on the device

Differentiation of participants is very important for the synchronization ecosystem because it enables us to see whether a participant can store the status information required by the provider, and whether we can directly run the provider on the device. In the end, the participant model will become a general model. Therefore, complete participants can be configured as partial or simple participants.

Complete participants

A complete participant is a device that allows developers to directly create applications and new data storage on the device. Laptops and smartphones are all participants, because you can execute new applications directly from this type of device and, if necessary, create new data storage to save information.

Some participants

Some participants are devices that can store data on devices. However, executable programs cannot be started directly from these devices. An important feature of some participants is that they can store the metadata required for synchronization, and thus be synchronized with any complete participant. An example of some participants is the U disk. These devices are similar to hard disks and can create, update, or delete information. However, they generally do not provide interfaces that allow applications to run directly on devices.

Simple participants

A simple participant is a device that can only provide information when a request is received. Such devices cannot store or operate on new data and do not support creating new applications. Simple participants rely on the full participants to store their metadata (so they can only be synchronized with specific full participants ).

RSS sources and Web services provided by external organizations (such as Amazon or EBay) are simple participants. These organizations may give you the ability to execute Web services and retrieve results, but they will not give you the ability to create your own data storage or execute your own applications on their Web servers.

Combined synchronization participants

The ultimate goal of Microsoft Sync Framework is to allow integration of data sources regardless of the type of participation they adopt. Therefore, simple and partial participants can synchronize information with the complete participants. However, at least one participant must be able to store information and start the synchronization process.

 

Sync Framework Core Components

The Sync Framework includes a set of "synchronization providers (synchronization providers)" at runtime for specific data storage areas, and an API for writing providers. The provider is a software component that communicates between the data source and other components in the synchronization system. If the Sync Framework already provides a provider for the data storage area to be synchronized, we strongly recommend that you use this provider. The providers are scalable so that you can customize them to suit your applications. If you want to synchronize the data storage areas of the providers that we do not provide or you need other implementations, use the custom providers.

Shows the relationship between all components in the Sync Framework.

The components in the figure are as follows:

• Database Synchronization provider (called Sync Services for ADO. NET in earlier versions ). These providers are included in Microsoft. synchronization. dll, Microsoft. synchronization. data. dll, Microsoft. synchronization. data. server. dll, Microsoft. synchronization. data. sqlServer. dll and Microsoft. synchronization. data. sqlServerCe. dll. They can be used to synchronize databases in the following types of scenarios:
  • Collaboration Solution. For example, in an application that allows users to share project remarks, project team members usually need a local copy of data that can be processed. When they make changes, they can synchronize with other team members to exchange changes, or synchronize changes with the central server.
  • Offline solution. For example, a salesperson needs to access product data in the customer's office and must be able to upload orders. The salesperson can synchronize with the central server every morning to ensure the latest product and price information, and then execute the synchronization above the day's order at night.
• File Sync provider (called Sync Services for File Systems in earlier versions ). This provider is included in FileSyncProvider21.dll and Microsoft. Synchronization. Files. dll. It can be used to synchronize files and folders in NTFS, FAT, or SMB file systems. The directory to be synchronized can be a local or remote directory without having to belong to the same file system. Applications can use static filters to exclude or include files by explicitly listing files or using wildcards (such as *. txt), or applications can set filters to exclude the entire subfolders. Applications can also be registered to receive notifications about file synchronization progress.
• The Web Feed synchronization component (called Sync Services for FeedSync in earlier versions ). These components are included in FeedSync21.dll and Microsoft. Synchronization. dll. You can use these components in two ways:
  • The Web Feed synchronization Provider Service can be used to compile a provider that expresses the FeedSync XML file as its copy.
  • The Web Feed generator and user components can be used to synchronize data from other types of copies (such as file systems) with RSS or Atom Feeds.
• Custom providers. These components are included in Synchronization21.dll and Microsoft. Synchronization. dll, SimpleProviders21.dll, and Microsoft. Synchronization. SimpleProviders. dll. They can be used to create synchronization providers for any type of data storage. For example, if an application includes a custom storage system for customer contact tracking, you can use a simple provider or a fully custom provider to integrate the data into your application.
• Metadata storage service. This component is included in MetaStore21.dll and Microsoft. Synchronization. MetadataStorage. dll. Custom providers can use this service as a convenient way to store and process synchronized metadata, especially for copies that cannot store metadata. The metadata storage service uses a reliable lightweight database that occupies a small amount of memory and disk space, and can be redistributed with the provider. This API separates the metadata storage area from the interface and method used to access the metadata storage area, which can achieve the backup storage area, the backup storage zone can be used if the provider is slightly changed.
• Core APIs and runtime. These components are included in Synchronization21.dll and Microsoft. Synchronization. dll. Core APIs and runtime are used by components other than offline database providers.

 

Sync Framework system architecture

The Sync Framework uses the provider-based architecture. The provider removes the complexity and specific implementation of each data storage zone from other synchronization components. This architecture works with a dedicated synchronization metadata so that the Sync Framework can simultaneously write any type of data storage area of the provider. Sync Framework provides common data storage areas (such as databases and NTFS file systems), and allows you to write providers for other types of storage areas. The provider is the main integration point of the Sync Framework.

Shows the Sync Framework's advanced architecture. Synchronization always happens between two copies (or "nodes") shown in the figure, but the synchronization community (or "Topology") can be in any shape, such as a central radiation, a pair, and so on. Except for some exceptions, each participant can synchronize on a 2-or n-tier architecture as required by the application. The documentation for each Sync Framework component provides detailed information about the corresponding architecture and security considerations.

There are three types of elements in the graph:

• Elements written by developers.
  • The application calls the synchronization method, responds to events, and processes other tasks as required by the application.
  • The data storage area can be a file system, relational database, a flat file contact storage area, or any other data storage area to be synchronized.
  • The data transmission protocol determines how data is transmitted between two providers.
• Elements provided by the Sync Framework.
  • Based on whether the local code is used or the managed code, the application communicates with the synchronization session or the synchronization controller, and the latter communicates with each synchronization provider.
  • The synchronization process is driven during synchronization and the client application is notified of the status, conflict, and error information.
• The elements written by developers or provided by the Sync Framework depend on the specific implementation scheme.
  • The provider is specific to the data type being synchronized. In some cases, applications must be customized by developers. The Sync Framework provides many APIs to simplify this process and some components to help complete the most difficult parts of synchronization (such as conflict detection ).
  • The metadata storage area contains metadata, which is used by Sync Framework to determine which changes should be selected by each provider and applied to the data storage area of the service. The way metadata is stored and used depends on the provider in use. For example, database providers generally store metadata in the tracking table of the database where the data storage area is located. For custom providers, you can create a metadata store or use the services provided with the Sync Framework.

After learning about the Core Components and system architecture of the Sync Framework, I will discuss in detail another key feature of the Sync Framework in the next article: Sync Metadata, that is, synchronize Metadata.