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 passe des événements via IWbemUnboundObjectSink en réponse à un ou plusieurs événements, comme défini 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 décrit 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 à l’aide du protocole COM.
Déterminez si vous souhaitez prendre en charge la notification d’événements synchrones ou asynchrones.
Avec la notification d’événement asynchrone, le thread d’envoi n’est pas lié au thread de réception. Par conséquent, ni WMI ni le fournisseur d’événements ne sont bloqués alors que WMI envoie une notification à tout consommateur inscrit pour recevoir l’événement. L’inconvénient de la remise asynchrone est qu’un changement de contexte se produit entre le moment où le fournisseur produit l’événement et le moment où le consommateur reçoit l’événement. Pour plus d’informations sur le travail de façon asynchrone, consultez la rubrique notions de base de com dans la section com du kit de développement logiciel (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 de la 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 le mode semi-synchrone au lieu de la communication asynchrone. Pour plus d’informations, consultez appel d’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, lorsqu’un fournisseur d’événements envoie une notification, le fournisseur d’événements est bloqué par WMI jusqu’à ce que WMI remette la notification. Uniquement si votre consommateur est extrêmement rapide et peut traiter un événement en microsecondes de 100 ou moins, si vous envisagez de prendre en charge la notification synchrone. Les consommateurs synchrones qui prennent trop de temps pour traiter les événements peuvent gravement ralentir la remise des événements à tous les autres consommateurs. En outre, ils peuvent bloquer le fournisseur par inadvertance. Pour plus d’informations, consultez liaison d’un filtre d’événements à un consommateur logique.
Implémentez la fonction IWbemUnboundObjectSink :: IndicateToConsumer .
WMI utilise la fonction IndicateToConsumer pour passer les pointeurs et les événements nécessaires à votre consommateur physique pour les communications synchrones et asynchrones. Votre implémentation de IndicateToConsumer doit contenir l’ensemble du 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 par le biais du fournisseur de consommateur 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 pour la 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 _ WbemAdministrativeLocator CLSID 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. Si vous n’utilisez pas l’identificateur _ WbemAdministrativeLocator CLSID dans l’appel CoCreateInstance , une erreur « Accès refusé » est générée.
Dans des circonstances habituelles, WMI fournit des événements asynchrones au client, l’un après l’autre. 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 en un seul appel. Le traitement automatique vous aide si les temps d’aller-retour sont un problème, comme c’est souvent le cas dans les scénarios à débit élevé. Toutefois, le traitement par lot n’améliore pas les performances du système si le client ou la bande passante réseau est défaillant.