Panoramica delle tecniche di Rilevamento modifiche

Esistono diversi modi in cui i meccanismi di rilevamento delle modifiche possono variare:

• Ambito per il rilevamento delle modifiche: un'applicazione può tenere traccia delle modifiche apportate a un singolo attributo di un singolo oggetto, a tutti gli oggetti di un dominio e così via. Se il meccanismo soddisfa i requisiti dell'applicazione, l'applicazione riceve un minimo di dati irrilevanti e quindi migliora le prestazioni.

• Tempestività: un'applicazione riceve una notifica di ogni modifica nel momento in cui si verifica o può ricevere una notifica dell'effetto netto delle modifiche in un periodo di minuti o ore.

  L'elaborazione di dati meno tempestivi può essere più efficiente, perché è possibile comprimere diverse modifiche in una. Ad esempio, se un attributo cambia tre volte entro un intervallo di un'ora, un'applicazione notifica delle modifiche accumulate in un'ora riceverà una notifica di una sola modifica dell'attributo, non di tre.

  Quando si pensa alla tempestività, considerare l'effetto della latenza di replica. Un aggiornamento che ha origine in un controller di dominio non viene replicato immediatamente in un altro controller di dominio. La richiesta di una tempestività di rilevamento delle modifiche molto migliore rispetto alla latenza di replica prevista spesso non offre alcun vantaggio reale all'applicazione.

• Polling e notifica: con il polling, un'applicazione effettua periodicamente una richiesta a un controller di dominio per ricevere i dati di rilevamento delle modifiche. Con la notifica il controller di dominio invia modifiche all'applicazione solo quando si verificano modifiche.

  Il sovraccarico del polling è ovvio: l'applicazione può richiedere dati di rilevamento delle modifiche quando non si è verificato nulla di significativo. Il sovraccarico della notifica è più sottile. Il server deve mantenere i dati sulle richieste di notifica e deve consultare questi dati per decidere se inviare o meno una notifica. Ciò può comportare un sovraccarico per le normali richieste di aggiornamento.

• Espressione delle conoscenze dell'applicazione: persistente e temporanea: ogni meccanismo di rilevamento delle modifiche deve includere un metodo per il server che contiene i dati monitorati per comprendere lo stato della conoscenza dell'applicazione, in modo che l'idea di "modifica" sia ben definita. Ad esempio, lo stato di conoscenza dell'applicazione potrebbe essere espresso come "Aggiornato con tutte le modifiche che si sono verificate nel controller di dominio d prima di time t". Un meccanismo basato su questo modo di esprimere lo stato di conoscenza di un'applicazione offre un modo efficiente per l'applicazione di ottenere modifiche che si sono verificate in un secondo momento rispetto a quello specificato.

  Se l'espressione delle conoscenze dell'applicazione può essere mantenuta, ovvero archiviata in modo recuperabile, come in un file o in un database, il riavvio dell'applicazione è meno intensivo delle risorse rispetto a se non è possibile. Nell'esempio precedente, l'espressione delle conoscenze dell'applicazione può essere mantenuta registrando il controller di dominio d e l'ora t. Alcuni meccanismi di notifica delle modifiche non consentono la persistenza di questi dati. Il server e l'applicazione devono essere sincronizzati con un altro meccanismo all'avvio dell'applicazione. Si tratta di un utilizzo intensivo delle risorse se sono coinvolti più oggetti e possono comportare una programmazione complessa.

Usare le tecniche seguenti per tenere traccia delle modifiche nei servizi di Dominio di Active Directory:

• Usare il controllo di notifica delle modifiche per avviare una ricerca asincrona persistente per le modifiche che corrispondono a un filtro specificato. Per altre informazioni, vedere Modificare le notifiche nei servizi di Dominio di Active Directory.
• Usare una ricerca di sincronizzazione della directory (DirSync) per recuperare le modifiche apportate dopo la ricerca di DirSync precedente. Per altre informazioni, vedere Polling for Changes Using the DirSync Control.For more information, see Polling for Changes Using the DirSync Control.
• Usare l'attributo USNChanged per cercare gli oggetti modificati dopo la ricerca precedente. Per altre informazioni, vedere Polling for Changes Using USNChanged .For more information, see Polling for Changes Using USNChanged.

Il controllo delle notifiche delle modifiche è progettato per applicazioni o servizi che richiedono una notifica ragionevolmente richiesta di modifiche poco frequenti. Un esempio è un servizio o un programma che archivia i dati di configurazione nel server Active Directory e deve ricevere una notifica tempestiva quando si verifica una modifica. Tenere presente che esistono limitazioni del controllo delle notifiche.

• La richiesta delle notifiche dipende dalla latenza di replica e dalla posizione in cui si è verificata la modifica. È possibile ricevere una notifica tempestiva quando una modifica viene replicata nella replica monitorata, ma la modifica potrebbe avere avuto origine molto prima in un'altra replica.
• Il controllo è limitato al monitoraggio di un singolo oggetto o degli elementi figlio immediati di un contenitore. Le applicazioni che devono monitorare più contenitori o oggetti non correlati possono registrare fino a cinque richieste di notifica.
• Se un numero eccessivo di client è in ascolto delle modifiche che si verificano frequentemente, influisce sulle prestazioni del server. In generale, le applicazioni devono limitare l'uso di questo controllo per motivi di prestazioni nel server. Se non è necessario conoscere immediatamente le modifiche, potrebbe essere preferibile eseguire periodicamente il polling delle modifiche anziché usare la notifica delle modifiche.

Le tecniche di ricerca DirSync e USNChanged sono progettate per le applicazioni che mantengono la coerenza tra i dati nel server Active Directory e i dati corrispondenti in altre risorse di archiviazione. Queste tecniche vengono usate dalle applicazioni che eseguono periodicamente il polling delle modifiche. La tecnica DirSync si basa su un controllo server LDAP che è possibile usare tramite LE API ADSI o LDAP. Gli svantaggi del controllo DirSync sono che possono essere usati solo da un account con privilegi elevati, ad esempio un amministratore di dominio. Di seguito è riportato un elenco delle limitazioni del controllo DirSync:

• Il controllo DirSync può essere usato solo da un account con privilegi elevati, ad esempio un amministratore di dominio.
• Il controllo DirSync può monitorare solo un intero contesto di denominazione. Non è possibile limitare l'ambito di una ricerca DirSync per monitorare solo un sottoalbero, un contenitore o un oggetto specifico in un contesto di denominazione.

La tecnica USNChanged non presenta queste limitazioni, anche se è un po' più complicata da usare rispetto a DirSync.