Implémentation d’un consommateur physique
Un consommateur physique est un objet COM qui implémente l’interface IWbemUnboundObjectSink. WMI charge votre consommateur physique et transmet des événements via IWbemUnboundObjectSink en réponse à un ou plusieurs événements, tels que définis par le consommateur logique associé. Les consommateurs permanents ont des exigences particulières en matière de sécurité. Pour plus d’informations, consultez Sécurisation des événements WMI.
La procédure suivante explique comment implémenter un consommateur physique pour un consommateur d’événements permanent.
Pour implémenter un consommateur physique pour un consommateur d’événements permanent
Créez un objet COM.
Vous devez implémenter un consommateur physique en tant que serveur local ou distant avec le protocole COM.
Déterminez si vous souhaitez prendre en charge la notification d’événement synchrone ou asynchrone.
Avec la notification d’événement asynchrone, le thread d’envoi n’est pas lié au thread de réception. Ainsi, ni WMI ni le fournisseur d’événements ne sont bloqués quand WMI remet une notification à tout consommateur inscrit pour recevoir l’événement. L’inconvénient de la remise asynchrone est qu’un changement de contexte a lieu entre le moment où le fournisseur produit l’événement et le moment où le consommateur le reçoit. Pour plus d’informations sur le fonctionnement asynchrone, consultez la rubrique Principes de base de COM dans la section COM du SDK Microsoft Windows. Pour plus d’informations sur les changements de contexte, consultez la rubrique Changements de contexte dans la section DLL, processus et threads du SDK Windows.
Notes
Étant donné que le rappel au récepteur peut ne pas être retourné au même niveau d’authentification que celui requis par le client, il est recommandé d’utiliser une communication semi-synchrone plutôt qu’une communication asynchrone. Pour plus d’informations, consultez Appeler une méthode.
Avec la notification synchrone, WMI remet la notification sur le même thread que celui utilisé par le fournisseur d’événements pour remettre l’événement à WMI. Dans ce cas, quand un fournisseur d’événements envoie une notification, le fournisseur d’événements est bloqué par WMI jusqu’à ce que WMI remette la notification. Ce n’est que si votre consommateur est extrêmement rapide et peut traiter un événement en 100 microsecondes ou moins que vous devez envisager de prendre en charge la notification synchrone. Les consommateurs synchrones qui prennent trop de temps pour traiter les événements peuvent sérieusement ralentir la remise d’événements à tous les autres consommateurs. En outre, ils peuvent bloquer par inadvertance le fournisseur. Pour plus d’informations, consultez Liaison d’un filtre d’événement à un consommateur logique.
Implémentez la fonction IWbemUnboundObjectSink::IndicateToConsumer.
WMI utilise la fonction IndicateToConsumer pour transmettre les pointeurs et les événements nécessaires à votre consommateur physique pour les communications synchrones et asynchrones. Votre implémentation d’IndicateToConsumer doit contenir tout le code nécessaire pour répondre à un événement.
Contrairement à un consommateur d’événements temporaire, vous n’avez pas besoin d’appeler l’interface IWbemLocator pour contacter WMI. Au lieu de cela, WMI localise un pointeur vers votre consommateur via le fournisseur de consommateurs d’événements. Pour plus d’informations, consultez Écriture d’un fournisseur de consommateur d’événements.
Toutefois, si vous souhaitez rappeler WMI, utilisez les interfaces IWbemLocator et IWbemServices. La méthode traditionnelle de connexion à WMI est pendant le processus d’initialisation de votre objet COM. Pour plus d’informations, consultez Création d’une application ou d’un script WMI.
Si vous implémentez votre consommateur physique en tant que serveur COM in-process et que vous vous connectez à WMI séparément du processus d’initialisation, vous devez utiliser l’identificateur de classe CLSID_WbemAdministrativeLocator pour accéder à l’interface IWbemLocator dans l’appel à CoCreateInstance.
L’exemple suivant montre comment utiliser l’identificateur de classe CLSID_WbemAdministrativeLocator pour accéder à l’interface IWbemLocator.
IWbemLocator *pLoc = 0; DWORD dwRes = CoCreateInstance(CLSID_WbemAdministrativeLocator, 0, CLSCTX_INPROC_SERVER, IID_IWbemLocator, (LPVOID *) &pLoc);L’interface IWbemLocator obtient le pointeur d’espace de noms initial vers WMI sur un ordinateur hôte particulier. L’échec de l’utilisation de l’identificateur CLSID_WbemAdministrativeLocator dans l’appel CoCreateInstance entraîne une erreur « accès refusé ».
Dans les circonstances habituelles, WMI remet les événements asynchrones au client un par un. Toutefois, si un client ne peut pas recevoir de notifications d’événements asynchrones aussi rapidement que les événements arrivent, WMI commence à traiter automatiquement les événements par lots en un seul appel. Le traitement automatique par lots est utile si les temps d’aller-retour sont un problème, comme c’est souvent le cas dans les scénarios à haut débit. Toutefois, le traitement par lots n’améliore pas les performances du système si le client ou la bande passante réseau sont en cause.