Condividi tramite


Nozioni fondamentali sui provider personalizzati

Microsoft Sync Framework include provider per diversi scenari di sincronizzazione come la sincronizzazione di file, ma in alcuni casi è necessario un provider personalizzato. I provider personalizzati richiedono che uno sviluppatore scriva più codice rispetto ai provider inclusi in Sync Framework, ma rappresentano un componente fondamentale per garantire la flessibilità e l'estensibilità di Sync Framework. In questo argomento vengono fornite informazioni che consentono di comprendere i provider personalizzati e di scegliere il tipo di provider personalizzato adatto all'applicazione. Se non si ha familiarità con Sync Framework, si consiglia inoltre di leggere la sezione "Componenti di Sync Framework" in Selezione dei componenti appropriati di Sync Framework.

Informazioni su provider, applicazioni e gestione dei metadati

Microsoft Sync Framework sincronizza le repliche tramite quattro componenti di base: il runtime di sincronizzazione, una sessione di sincronizzazione e due provider di sincronizzazione. Per sincronizzare i dati, un'applicazione crea una sessione di sincronizzazione e la passa a un provider di origine e a un provider di destinazione. La sessione utilizza il provider di origine per ottenere le nuove modifiche che si sono verificate nella replica di origine e utilizza il provider di destinazione per applicare queste modifiche alla replica di destinazione. Un provider gestisce i metadati, inclusa la conoscenza, per ogni replica e per ogni elemento che deve essere sincronizzato. La conoscenza rappresenta i metadati che descrivono tutte le modifiche applicate a una replica, direttamente o tramite la sincronizzazione.

Quando Sync Framework non fornisce un provider per l'archivio dati da sincronizzare, deve essere scritto un provider personalizzato. Sync Framework include API gestite e non gestite per due tipi di provider personalizzati, provider personalizzati semplici e provider personalizzati standard:

  • Grazie a un minor numero di interfacce e alla semplicità che le caratterizza, i provider semplici offrono una maggior velocità di sviluppo e un supporto più intuitivo per archivi dati che non dispongono di sofisticati meccanismi di rilevamento delle modifiche.

  • I provider standard offrono la più ampia flessibilità e i livelli più elevati di prestazioni e affidabilità.

Entrambi i tipi di provider possono essere utilizzati per sincronizzare un'ampia gamma di archivi dati e forniscono opzioni in aree importanti quali l'applicazione di filtri e la gestione dei conflitti. Esistono tuttavia differenze significative. Per ulteriori informazioni, vedere "Scelta tra un provider semplice e un provider standard" in questo argomento.

Nell'illustrazione seguente vengono mostrati gli elementi principali utilizzati in uno scenario di sincronizzazione. L'illustrazione è simile a quella in Selezione dei componenti appropriati di Sync Framework, ma il testo associato fornisce informazioni aggiuntive attinenti ai provider personalizzati e mostra il flusso di dati e metadati nel sistema.

Architettura di provider di sincronizzazione personalizzata

Gli elementi nell'illustrazione sono di tre tipi:

  • Elementi scritti dallo sviluppatore.

  • Elementi forniti da Sync Framework.

    • A seconda che il codice utilizzato sia gestito o non gestito, l'applicazione comunica con un agente di orchestrazione della sincronizzazione (SyncOrchestrator) o una sessione di sincronizzazione (ISyncSession) che a sua volta comunica con ciascun provider di sincronizzazione, guida il processo di sincronizzazione e segnala lo stato, i conflitti e gli errori all'applicazione client.

    • Il runtime di sincronizzazione supporta i provider nell'esecuzione delle comuni attività di sincronizzazione, ad esempio la gestione dei metadati, il rilevamento dei conflitti e l'applicazione delle modifiche.

  • Elementi scritti dallo sviluppatore o forniti da Sync Framework, a seconda dei requisiti del provider e dell'applicazione.

    • L'archivio dei metadati contiene i metadati utilizzati da Sync Framework per determinare le modifiche che ogni provider deve selezionare e applicare all'archivio dati servito. L'archivio dei metadati può essere separato dall'archivio dati (come file separato o database) o integrato nell'archivio (come tabella aggiuntiva in un database). In genere, il provider di sincronizzazione gestisce i metadati necessari per la sincronizzazione. Tuttavia, a seconda dell'implementazione della replica, potrebbe essere più utile che alcuni aspetti della gestione dei metadati vengano curati da un componente separato, ad esempio un servizio che esegue la pulizia dei metadati meno recenti a orari pianificati anziché durante la sincronizzazione. I metadati necessari e il modo in cui vengono archiviati e utilizzati dipendono dal provider utilizzato. Per informazioni sui requisiti dei metadati per ciascun tipo di provider, vedere Gestione dei metadati per provider semplici e Requisiti dei metadati per i provider standard.

      Il provider semplice separa quasi completamente lo sviluppatore dall'interazione con l'archivio dei metadati. Utilizza un'implementazione del servizio di archiviazione dei metadati inclusa in Sync Framework. Nei provider personalizzati standard è possibile utilizzare questa implementazione oppure un'altra basata sull'API del servizio di archiviazione dei metadati oppure un'implementazione completamente personalizzata che archivia i metadati in un archivio separato o all'interno dell'archivio dati. Per ulteriori informazioni, vedere Gestione dei metadati per provider standard.

Scelta tra un provider semplice e un provider standard

Nella maggior parte dei casi si consiglia l'utilizzo di un provider semplice, ma è prima necessario comprendere le ipotesi avanzate in fase di progettazione dell'API di un provider semplice:

  • Gli archivi dati da sincronizzare non supportano alcun tipo di rilevamento delle modifiche o supportano solo il rilevamento delle modifiche basato su ancoraggio.

    Un ancoraggio è un oggetto che indica gli elementi di un archivio dati che sono stati modificati dall'ultima sessione di sincronizzazione. Negli archivi che non dispongono del rilevamento delle modifiche o che dispongono solo del rilevamento delle modifiche basato su ancoraggio, si verificano aggiornamenti alla conoscenza della sincronizzazione durante la sessione di sincronizzazione (in modo asincrono), non quando si verifica la modifica nell'archivio (in modo sincrono). Se si verificano contemporaneamente molte sessioni di sincronizzazione su una particolare replica, ciò può influire sulle prestazioni. Pertanto, se un'applicazione richiede un'elevata concorrenza e ogni archivio dati supporta aggiornamenti sincroni alla conoscenza della sincronizzazione, utilizzare un provider standard.

  • La replica richiede la sincronizzazione di un solo tipo di elemento.

  • A causa delle limitazioni dell'archivio dati o dei requisiti dell'applicazione, è necessario archiviare i metadati all'esterno dell'archivio dati.

    Nei provider semplici i metadati vengono archiviati tramite l'implementazione del servizio di archiviazione dei metadati incluso in Sync Framework. I metadati vengono archiviati separatamente dai dati che descrivono, situazione che presenta due potenziali problemi:

    • Se i metadati vengono archiviati in remoto, potrebbero non essere disponibili durante una sessione di sincronizzazione. Ad esempio, è disponibile la connessione di rete tra le due repliche da sincronizzare, ma non la connessione al server che ospita i metadati.

    • La coerenza transazionale tra dati e metadati non è garantita. Si consiglia di archiviare i metadati nello stesso computer dei dati, ma il supporto transazionale non è disponibile a meno che non si utilizzi un provider standard e si archivino i metadati nell'archivio dati (o si utilizzi una transazione distribuita per aggiornare entrambi gli archivi). Nei provider standard è anche possibile utilizzare il servizio di archiviazione dei metadati, ma ciò non è richiesto come per i provider semplici.

Se i requisiti dell'applicazione corrispondono a queste ipotesi, si consiglia di utilizzare provider semplici. Per ulteriori informazioni sui provider semplici, vedere Implementazione di un provider personalizzato semplice. Per ulteriori informazioni sui provider standard, vedere Implementazione di un provider standard personalizzato.

Informazioni sui tipi partecipanti di Sync Framework

Sync Framework può essere utilizzato per sincronizzare dati fra partecipanti con funzionalità variabili. Un partecipante è un dispositivo o un servizio in grado di eseguire la sincronizzazione con altri sistemi in cui è in esecuzione Sync Framework.

Sync Framework supporta i tipi partecipanti seguenti:

  • Partecipante completo

  • Partecipante proxy

  • Partecipante parziale

  • Partecipante semplice

Partecipante completo

Un partecipante completo ospita il runtime e archivia i metadati in locale. I partecipanti completi possono prendere parte agli scenari di sincronizzazione peer-to-peer poiché entrambi i partecipanti sono in grado di avviare la sincronizzazione.

Due partecipanti completi nella sincronizzazione peer-to-peer

Componenti partecipanti completi

Partecipante parziale

Un partecipante parziale può archiviare metadati per la sincronizzazione ma non può elaborarli. Un partecipante parziale si basa su diversi partecipanti completi per ospitare il runtime e avviare la sincronizzazione. Il flusso dei dati è consentito tra questi partecipanti poiché possono trasportare i metadati per la sincronizzazione multimaster e comunicarli a qualsiasi altro partecipante completo. I partecipanti parziali non possono prendere parte a scenari peer-to-peer a causa della loro impossibilità di elaborare i metadati o di ospitare il runtime. Alcuni esempi di partecipanti parziali sono le unità USB e i telefoni cellulari con funzionalità di memorizzazione dei dati.

Di seguito viene illustrata la modalità in cui un partecipante completo, ad esempio un computer, esegue la sincronizzazione con un partecipante parziale, ad esempio un telefono cellulare. Il partecipante completo enumera o filtra le modifiche per conto del partecipante parziale e archivia i metadati sul partecipante parziale. In questo modo tutti gli altri partecipanti completi possono eseguire la sincronizzazione con questo partecipante parziale.

Sincronizzazione di un partecipante completo con un partecipante parziale

Componenti partecipanti completi e parziali

Partecipante semplice

In un partecipante semplice non vengono archiviati i metadati, non viene ospitato il runtime e il rilevamento delle modifiche potrebbe non essere disponibile. Un partecipante semplice si basa su un unico partecipante completo per eseguire tutte le operazioni relative all'enumerazione delle modifiche, alla loro applicazione, alla modifica e all'archiviazione dei metadati. Poiché in un partecipante semplice non vengono archiviati i metadati, può essere utilizzato solo come nodo foglia il cui partner è un unico partecipante completo che trasferisce dati da e verso qualsiasi altro partecipante.

Di seguito viene illustrato un partecipante completo che utilizza il servizio di archiviazione dei metadati per archiviare metadati per un partecipante semplice e che gestisce tutti gli aspetti della sincronizzazione per conto del partecipante semplice. L'archivio dei metadati viene utilizzato per tenere traccia delle modifiche correlate al partecipante semplice ma viene archiviato nel partecipante completo a causa delle limitazioni di archiviazione del partecipante semplice.

Partecipante completo che utilizza il servizio di archiviazione dei metadati per sincronizzare un partecipante semplice

Componenti partecipanti completi e semplici

Partecipante proxy

Un partecipante proxy avvia la sincronizzazione per un provider remoto gestendo le chiamate in locale e inoltrandole al provider remoto, ad esempio un database archiviato in un server.

Security noteSicurezza Nota

In Sync Framework non viene fornita l'autenticazione o la crittografia tra il provider proxy e il provider remoto. Per impedire manomissioni o accessi non autorizzati, è necessario proteggere il canale di comunicazione tra il provider proxy e il provider remoto tramite un'autenticazione reciproca o un meccanismo di crittografia appropriato, ad esempio Secure Sockets Layer (SSL).

Nell'illustrazione seguente è rappresentato un provider partecipante completo che esegue la sincronizzazione con un provider proxy. Si noti che il provider proxy invia unicamente i comandi e i metadati in rete al provider remoto. Il provider remoto si trova nel server database e implementa la logica effettiva utilizzata per la sincronizzazione. La riga rossa tratteggiata rappresenta un limite del computer.

Sincronizzazione di un partecipante completo con un partecipante proxy

Componenti partecipanti completi e proxy

Di seguito viene illustrato come utilizzare Sync Framework per sincronizzare i provider remoti rispetto all'applicazione da cui viene avviata la sincronizzazione. L'applicazione di controllo può connettere due servizi Web o Smart Device da sincronizzare. Si noti che entrambi i provider locali sono provider proxy rispetto ai provider remoti. Le righe rosse tratteggiate rappresentano i limiti del computer.

Sincronizzazione di un'applicazione centrale con due partecipanti proxy

Componenti partecipanti di applicazione e proxy

Vedere anche

Concetti

Selezione dei componenti appropriati di Sync Framework
Implementazione di un provider personalizzato semplice
Implementazione di un provider standard personalizzato
Implementazione di un'applicazione di sincronizzazione
Esempi di Sync Framework