Visão geral das técnicas de controle de alterações

Há várias maneiras pelas quais os mecanismos de controle de alterações podem diferir:

• Escopo para controlar alterações: um aplicativo pode controlar alterações em um único atributo de um único objeto, em todos os objetos em um domínio e assim por diante. Se o mecanismo corresponder aos requisitos do aplicativo, o aplicativo receberá um mínimo de dados irrelevantes e, portanto, isso melhorará o desempenho.

• Pontualidade: Um aplicativo é notificado de cada alteração à medida que ela acontece, ou pode ser notificado do efeito líquido das alterações durante um período de minutos ou horas.

  O processamento de dados menos oportunos pode ser mais eficiente, porque várias alterações podem ser recolhidas em uma. Por exemplo, se um atributo for alterado três vezes em um intervalo de uma hora, um aplicativo notificado sobre alterações acumuladas ao longo de uma hora será notificado de apenas uma alteração de atributo, e não três.

  Ao pensar em pontualidade, considere o efeito da latência de replicação. Uma atualização originada em um controlador de domínio não é replicada para outro controlador de domínio instantaneamente. Exigir tempo de controle de alterações muito melhor do que a latência de replicação esperada geralmente não oferece nenhum benefício real ao aplicativo.

• Sondagem versus notificação: com a sondagem, um aplicativo faz periodicamente uma solicitação a um controlador de domínio para receber dados de controle de alterações. Com a notificação, o controlador de domínio envia alterações para o aplicativo somente quando ocorrem alterações.

  A sobrecarga da sondagem é óbvia: o aplicativo pode solicitar dados de controle de alterações quando nada significativo tiver ocorrido. A sobrecarga de notificação é mais sutil. O servidor deve manter dados sobre solicitações de notificação e deve consultar esses dados para decidir se deseja ou não enviar uma notificação. Isso pode adicionar sobrecarga às solicitações de atualização normais.

• Expressando o conhecimento do aplicativo: persistente versus temporário: Todo mecanismo de controle de alterações deve incluir algum método para que o servidor que mantém os dados rastreados entenda o estado de conhecimento do aplicativo, para que a ideia de "mudança" seja bem definida. Por exemplo, o estado de conhecimento do aplicativo pode ser expresso como "Atualizado com todas as alterações que ocorreram no DC d antes do tempo t". Um mecanismo baseado nessa maneira de expressar o estado de conhecimento de um aplicativo forneceria uma maneira eficiente para o aplicativo obter alterações que ocorreram depois de um tempo especificado.

  Se a expressão do conhecimento do aplicativo puder ser persistente, ou seja, armazenada de forma recuperável, como em um arquivo ou banco de dados, a reinicialização do aplicativo consome menos recursos do que se não puder. No exemplo acima, a expressão do conhecimento do aplicativo pode ser mantida registrando o DC d e o tempo t. Alguns mecanismos de notificação de alterações não permitem que esses dados sejam mantidos. O servidor e o aplicativo devem ser sincronizados com algum outro mecanismo quando o aplicativo é iniciado. Isso consome muitos recursos se vários objetos estiverem envolvidos e pode envolver programação complexa.

Use as seguintes técnicas para controlar as alterações nos Serviços de Domínio Active Directory:

• Use o controle de notificação de alteração para iniciar uma pesquisa assíncrona persistente para alterações que correspondam a um filtro especificado. Para obter mais informações, consulte Alterar notificações nos Serviços de Domínio Active Directory.
• Use uma pesquisa de sincronização de diretórios (DirSync) para recuperar alterações que ocorreram desde a pesquisa anterior do DirSync. Para obter mais informações, consulte Sondagem para alterações usando o controle DirSync.
• Use o atributo USNChanged para procurar objetos que foram alterados desde a pesquisa anterior. Para obter mais informações, consulte Sondagem para alterações usando USNChanged.

O controle de notificação de alteração foi projetado para aplicativos ou serviços que exigem notificação razoavelmente rápida de alterações pouco frequentes. Um exemplo é um serviço ou programa que armazena dados de configuração no servidor do Active Directory e deve ser notificado imediatamente quando ocorrer uma alteração. Esteja ciente de que há limitações do controle de notificação.

• A rapidez das notificações depende da latência de replicação e de onde a alteração ocorreu. Você pode ser notificado imediatamente quando uma alteração for replicada na réplica que você está monitorando, mas a alteração pode ter se originado muito antes em alguma outra réplica.
• O controle é restrito ao monitoramento de um único objeto ou dos filhos imediatos de um contêiner. Os aplicativos que devem monitorar vários contêineres ou objetos não relacionados podem registrar até cinco solicitações de notificação.
• Se muitos clientes estiverem ouvindo alterações que ocorrem com frequência, isso afetará o desempenho do servidor. Em geral, os aplicativos devem limitar o uso desse controle por motivos de desempenho no servidor. Se você não precisar saber sobre as alterações imediatamente, talvez seja melhor pesquisar periodicamente as alterações em vez de usar a notificação de alterações.

As técnicas de pesquisa DirSync e USNChanged são projetadas para aplicativos que mantêm a consistência entre os dados no servidor do Active Directory e os dados correspondentes em algum outro armazenamento. Essas técnicas são usadas por aplicativos que pesquisam periodicamente se há alterações. A técnica DirSync é baseada em um controle de servidor LDAP que você pode usar por meio de APIs ADSI ou LDAP. As desvantagens do controle DirSync são que ele só pode ser usado por uma conta altamente privilegiada, como um administrador de domínio. A seguir está uma lista de limitações do controle DirSync:

• O controle DirSync só pode ser usado por uma conta altamente privilegiada, como um administrador de domínio.
• O controle DirSync só pode monitorar um contexto de nomenclatura inteiro. Não é possível limitar o escopo de uma pesquisa do DirSync para monitorar apenas uma subárvore, contêiner ou objeto específico em um contexto de nomenclatura.

A técnica USNChanged não tem essas limitações, embora seja um pouco mais complicada de usar do que o DirSync.