How does it work¶
Basically, DMS architecture is composed of several business objects:
Providers : A provider is in charge of the communication with the local database. You can choose various providers, like
SQL
,MySQL
,MariaDB
orSqlite
. Each provider can work on both side of the sync architecture : Server side or Client side.Orchestrators : An orchestrator is agnostic to the underlying database. it communicates with the database through a provider. A provider is always required when you’re creating a new orchestrator. We have two kind of orchestrator : local and remote (or let’s say client side and server side orchestrators)
SyncAgent: There is only one sync agent. This object is responsible of the correct flow between two orchestrators. The sync agent will:
Create a local orchestrator with a typed provider.
Create a remote orchestrator with a typed provider.
Synchronize client and server, using all the methods from the orchestrators.
Overview¶
Here is the big picture of the components used in a simple synchronization, over TCP:
If we take a close look to the HelloSync sample:
var serverProvider = new MySqlSyncProvider(serverConnectionString);
var clientProvider = new SqliteSyncProvider(clientConnectionString);
var setup = new SyncSetup("ProductCategory", "ProductModel", "Product");
var agent = new SyncAgent(clientProvider, serverProvider);
var result = await agent.SynchronizeAsync(setup);
Console.WriteLine(result);
There is no mention of any Orchestrators
here.
SyncAgent
instance will create them under the hood, for simplicity.// Create 2 providers, one for MySql, one for Sqlite.
var serverProvider = new MySqlSyncProvider(serverConnectionString);
var clientProvider = new SqliteSyncProvider(clientConnectionString);
// Setup and options define the tables and some useful options.
var setup = new SyncSetup("ProductCategory", "ProductModel", "Product");
// Define a local orchestrator, using the Sqlite provider
// and a remote orchestrator, using the MySql provider.
var localOrchestrator = new LocalOrchestrator(clientProvider);
var remoteOrchestrator = new RemoteOrchestrator(serverProvider);
// Create the agent with existing orchestrators
var agent = new SyncAgent(localOrchestrator, remoteOrchestrator);
// Launch the sync
var result = await agent.SynchronizeAsync(setup);
Console.WriteLine(result);
As you can see here, all the components are declared:
Each provider : One Sqlite and One MySql
Each orchestrator : a local orchestrator coupled with the Sqlite provider and a remote orchestrator coupled with the MySql provider
One sync agent : The sync agent instance needs of course both orchestrators to be able to launch the sync process.
Multiple clients overview¶
Of course, a real scenario will involve more clients databases. Each client will have its own provider, depending on the local database type. And each client will have a sync agent, responsible of the sync process:
Sync over HTTP¶
In a real world scenario, you may want to protect your hub database (the server side database), if your clients are not part of your local network, like mobile devices which will communicate only through an http connection. In this particular scenario, the sync agent will not be able to use a simple RemoteOrchestrator, since this one works only on a tcp network. Here is coming a new orchestrator in the game. Or shoud I say two new orchestrators:
The
WebRemoteOrchestrator
: This orchestrator will run locally, and will act “as” a orchestrator from the sync agent, but under the hood will generate an http request with a payload containing all the required informationThe
WebServerAgent
: On the opposite side, this web server agent is hosted through an exposed web api, and will get the incoming request from theWebRemoteOrchestrator
and will then call the server provider correctly.
Here is the big picture of this more advanced scenario:
You can read more on the web architecture and how to implement it, here: Asp.net Core Web Api sync proxy