Sync Framework Core Participant Types
Sync Framework can be used to synchronize data among participants of varying functionality. A participant is a device or service that can synchronize with other systems that are running Sync Framework.
Sync Framework supports the following types of participants:
A full participant locally hosts the runtime and stores metadata. Full participants can take part in peer-to-peer synchronization scenarios because both participants can start synchronization.
A proxy participant starts synchronization for a remote provider by handling calls locally and forwarding them to the remote provider, such as a database that is stored on a server.
Sync Framework does not provide authentication or encryption between the proxy provider and the remote provider. To help prevent unauthorized access or tampering, the communication channel between the proxy provider and the remote provider must be secured by using an appropriate mutual authentication and encryption mechanism, such as Secure Sockets Layer (SSL).
The following illustration shows a full participant provider synchronizing with a proxy provider. Notice that the proxy provider just sends commands and metadata over the network to the remote provider. The remote provider exists on the database server and implements the actual logic that is used for the synchronization. The dashed red line represents a computer boundary.
The following illustration shows how the Sync Framework can be used to synchronize providers that are remote to the application that starts synchronization. The controlling application could be connecting two Web services or smart devices that must be synchronized. Notice that both local providers are proxy providers to the remote providers. The dashed red lines represent computer boundaries.
A partial participant can store synchronization metadata but cannot process it. A partial participant relies on several full participants to host the runtime and start synchronization. Data can flow through these participants because they can carry the multimaster synchronization metadata and communicate this metadata with any other full participant. Partial participants cannot take part in peer-to-peer scenarios because of their inability to process the metadata or host the runtime. Some examples of partial participants are USB thumb drives and mobile phones that have data storage capabilities.
The following illustration shows how a full participant, such as a computer, synchronizes with a partial participant, such as a mobile phone. The full participant enumerates or filters changes on behalf of the partial participant and stores the metadata on the partial participant. This enables any other full participant to synchronize this partial participant.
A simple participant does not store metadata, cannot house the runtime, and might not have change tracking. Instead, a simple participant relies on a single full participant to do everything with regard to enumerating changes, applying changes, and manipulating and storing the metadata. Because a simple participant cannot store metadata, it can only act as a leaf node that is partnered with a single full participant that transfers data to and from any other participants.
The following illustration shows a full participant that uses Metadata Storage Service to store metadata for a simple participant and that drives all aspects of synchronization on behalf of the simple participant. The metadata store is used to track changes related to the simple participant but is stored on the full participant because of the storage limitations of the simple participant.