Optimización de un proveedor de eventos

Un proveedor de eventos puede dedicar mucho tiempo a crear eventos. Si ninguna aplicación cliente usa los eventos creados, el proveedor está desperdiciando recursos del sistema. Además, WMI dedica una cantidad considerable de recursos a analizar y enviar consultas complejas al proveedor adecuado. Para evitar el desperdicio de recursos del sistema y mejorar el rendimiento del proveedor de eventos, puede implementar la interfaz IWbemEventProviderQuerySink. IWbemEventProviderQuerySink supervisa las consultas que las aplicaciones cliente registran con WMI mediante los métodos NewQuery y CancelQuery. Al supervisar las consultas de cliente registradas, el proveedor puede determinar qué ocurre si se deben enviar mensajes a WMI.

WMI llama a NewQuery en un proveedor de eventos cuando un consumidor de cliente registra una consulta de filtro de eventos que contiene referencias a eventos admitidos por ese proveedor de eventos. Por lo tanto, el proveedor de eventos responsable de los eventos de modificación de instancias de la clase EmailClass se puede configurar para generar notificaciones solo para el remitente. Cuando el proveedor recibe una consulta que solicita notificaciones de cambios en la propiedad subject, el proveedor puede empezar a generar esas notificaciones. En este escenario, WMI no es necesario para descartar las notificaciones que solo cambian los destinatarios del informe.

De forma similar, WMI llama a CancelQuery en un proveedor de eventos cuando un consumidor de cliente anula el registro una consulta de filtro de eventos que contiene referencias a eventos admitidos por el proveedor de eventos. La finalidad de CancelQuery es que el proveedor de eventos actualice la lista de eventos que se deben enviar.

Nota

Si el proveedor admite tanto IWbemEventProvider como IWbemEventProviderQuerySink, asegúrese de que la implementación del método IUnknown::QueryInterface devuelve punteros a ambas interfaces.