Otimizar um provedor de eventos

Um provedor de eventos pode dedicar muito tempo à criação de eventos. Se nenhum aplicativo cliente usar os eventos criados, o provedor estará desperdiçando recursos do sistema. Além disso, o WMI gasta uma quantidade considerável de recursos analisando e enviando consultas complexas para o provedor apropriado. Para evitar o desperdício de recursos do sistema e melhorar o desempenho do provedor de eventos, você pode implementar a interface IWbemEventProviderQuerySink. O IWbemEventProviderQuerySink monitora as consultas que os aplicativos cliente registram no WMI usando os métodos NewQuery e CancelQuery. Ao monitorar as consultas de cliente registradas, seu provedor pode determinar se alguma mensagem deve ser enviada ao WMI.

O WMI chama NewQuery em um provedor de eventos quando um consumidor cliente registra uma consulta de filtro de evento que contém referências a eventos compatíveis com esse provedor de eventos. Portanto, o provedor de eventos responsável por eventos de modificação de instância para a classe EmailClass pode ser configurado para gerar notificações somente para o remetente. Quando o provedor recebe uma consulta solicitando a notificação de alterações na propriedade assunto, o provedor pode começar a gerar essas notificações. Nesse cenário, não é necessário que o WMI descarte as notificações que relatam mudanças apenas no destinatário.

Da mesma forma, o WMI chama o CancelQuery em um provedor de eventos quando um consumidor cliente cancela o registro de uma consulta de filtro de evento que contém referências a eventos com suporte do provedor de eventos. A finalidade do CancelQuery é que o provedor de eventos atualize a lista de quais eventos devem ser enviados.

Observação

Se o provedor der suporte a IWbemEventProvider e IWbemEventProviderQuerySink, verifique se a implementação do método IUnknown::QueryInterface retorna ponteiros para ambas as interfaces.