|
Tout d'abord pourquoi utiliser WCF dans une architecture déconnectée ?
A cela, plusieurs réponses, d'ordre logique et d'architecture, plus que technique : - Le client ne peut pas ouvrir de connexion directe sur le serveur de données : Précaution assez induite par le fait qu'il est bien plus préférable d'exposer une assembly .NET sous WCF qu'exposer un serveur SQL SERVER 2005!
- la Communication doit se faire via un protocole de type HTTP. WCF prend en compte des binding comme WsHttpBinding ou encore BasicHttpBinding, nous allons donc en tirer parti.
- Il existe déjà une architecture WCF, sur laquelle on veut pouvoir supporter une synchronisation déconnectée.
A ces quelques arguments, Sync. Services for ADO.Net apporte la solution, qui plus est, totalement intégrée : - Sync Services est déjà prêt pour WCF.
- Le Designer permet de créer une architecture autour de WCF et génère les classes pour le service métier ainsi que l'application cliente.
Sur une architecture non distribuée, le découpage des éléments, simple, constituant notre synchronisation est le suivant : - Le fournisseur de synchronisation client : Le ClientSyncProvider.
- Le fournisseur de synchronisation serveur : Le ServerSyncProvider.
- Le coordinateur de synchronisation : Le SyncAgent.
Les autres éléments, SyncAdapter, SyncTable, Syncgroups sont des sous éléments des 3 éléments de plus haut niveaux. Pour le découpage multi tiers, nous allons arriver à cette solution : On remarque 3 éléments à prendre en compte : - Le coordinateur de synchronisation (SyncAgent), reste sur l'application cliente : Logique : il est le seul à connaître le fournisseur client (qui peut être différent suivant le client d'ailleurs !)
- Le fournisseur de synchronisation serveur sera donc hébergé par notre serveur de services WCF.
- Notre agent de synchronisation passera donc par un proxy pour appeler le fournisseur de synchronisation serveur.
|
|
|
|
|