Implementieren eines physischen Consumers

Ein physischer Consumer ist ein COM-Objekt, das die IWbemUnboundObjectSink-Schnittstelle implementiert. WMI lädt Ihren physischen Consumer und übergibt Ereignisse über IWbemUnboundObjectSink als Reaktion auf ein oder mehrere Ereignisse, wie vom zugeordneten logischen Consumer definiert. Für permanente Consumer gelten besondere Sicherheitsanforderungen. Weitere Informationen finden Sie unter Schützen von WMI-Ereignissen.

Im folgenden Verfahren wird beschrieben, wie Sie einen physischen Consumer für einen permanenten Ereignisconsumer implementieren.

So implementieren Sie einen physischen Consumer für einen permanenten Ereignisconsumer

1. Erstellen Sie ein COM-Objekt.

   Sie müssen einen physischen Consumer mithilfe des COM-Protokolls als lokalen Server oder Remoteserver implementieren.

2. Ermitteln Sie, ob synchrone oder asynchrone Ereignisbenachrichtigungen unterstützt werden sollen.

   Bei asynchroner Ereignisbenachrichtigung steht der sendende Thread nicht mit dem empfangenden Thread in Verbindung. Daher werden weder WMI noch der Ereignisanbieter blockiert, während WMI eine Benachrichtigung an alle Consumer sendet, die zum Empfangen des Ereignisses registriert sind. Der Nachteil der asynchronen Übermittlung besteht darin, dass zwischen dem Zeitpunkt, zu dem der Anbieter das Ereignis erzeugt, und dem Zeitpunkt, zu dem der Consumer das Ereignis empfängt, ein Kontextwechsel stattfindet. Weitere Informationen zum asynchronen Arbeiten finden Sie im Thema COM-Grundlagen im Abschnitt „COM“ des Microsoft Windows Software Development Kit (SDK). Weitere Informationen zum Kontextwechsel finden Sie im Thema Kontextwechsel im Abschnitt zu DLLs, Prozessen und Threads des Windows SDK.

   Hinweis

   Da der Rückruf an die Senke möglicherweise nicht auf der Authentifizierungsebene zurückgegeben wird, die der Client benötigt, empfiehlt es sich, anstelle der asynchronen Kommunikation eine halbsynchrone Kommunikation zu verwenden. Weitere Informationen finden Sie unter Aufrufen einer Methode.

    

   Bei synchroner Benachrichtigung sendet WMI die Benachrichtigung im selben Thread, den der Ereignisanbieter zum Übermitteln des Ereignisses an WMI verwendet hat. Wenn in diesem Fall ein Ereignisanbieter eine Benachrichtigung sendet, wird der Ereignisanbieter von WMI blockiert, bis WMI die Benachrichtigung übermittelt. Nur wenn Ihr Consumer extrem schnell ist und ein Ereignis in 100 Mikrosekunden oder weniger verarbeiten kann, sollten Sie die Unterstützung synchroner Benachrichtigungen in Erwägung ziehen. Synchrone Consumer, bei denen die Verarbeitung von Ereignissen zu lange dauert, können die Übermittlung von Ereignissen an alle anderen Consumer erheblich verlangsamen. Darüber hinaus können sie den Anbieter versehentlich blockieren. Weitere Informationen finden Sie unter Bindung eines Ereignisfilters mit einem logischen Consumer.

3. Implementieren Sie die IWbemUnboundObjectSink::IndicateToConsumer-Funktion.

   WMI verwendet die Funktion IndicateToConsumer, um die erforderlichen Zeiger und Ereignisse an Ihren physischen Consumer für synchrone und asynchrone Kommunikation zu übergeben. Ihre Implementierung von IndicateToConsumer sollte den gesamten erforderlichen Code enthalten, um auf ein Ereignis zu reagieren.

   Im Gegensatz zu einem temporären Ereignisconsumer müssen Sie die IWbemLocator-Schnittstelle nicht aufrufen, um WMI zu kontaktieren. Stattdessen sucht WMI über den Ereignisconsumeranbieter einen Zeiger auf Ihren Consumer. Weitere Informationen finden Sie unter Schreiben eines Ereignisconsumeranbieters.

   Wenn Sie jedoch einen Rückruf in WMI ausführen möchten, verwenden Sie die Schnittstellen IWbemLocator und IWbemServices. Die herkömmliche Methode zum Herstellen einer Verbindung mit WMI wird während des Initialisierungsprozesses Ihres COM-Objekts ausgeführt. Weitere Informationen finden Sie unter Erstellen einer WMI-Anwendung oder eines WMI-Skripts.

   Wenn Sie Ihren physischen Consumer als prozessinternen COM-Server implementieren und eine Verbindung mit WMI unabhängig vom Initialisierungsprozess herstellen, müssen Sie den Klassenbezeichner CLSID_WbemAdministrativeLocator verwenden, um im Aufruf von CoCreateInstance auf die IWbemLocator-Schnittstelle zuzugreifen.

   Das folgende Beispiel zeigt, wie Sie den Klassenbezeichner CLSID_WbemAdministrativeLocator verwenden, um auf die IWbemLocator-Schnittstelle zuzugreifen.

   IWbemLocator *pLoc = 0;
   
   DWORD dwRes = CoCreateInstance(CLSID_WbemAdministrativeLocator, 0, 
       CLSCTX_INPROC_SERVER, IID_IWbemLocator, (LPVOID *) &pLoc);
   

   Die IWbemLocator-Schnittstelle ruft den anfänglichen Namespacezeiger auf WMI auf einem bestimmten Hostcomputer ab. Ein Fehler bei der Verwendung des Bezeichners CLSID_WbemAdministrativeLocator im CoCreateInstance-Aufruf führt zu einem Fehler vom Typ „Zugriff verweigert“.

   Unter normalen Umständen übermittelt WMI asynchrone Ereignisse nacheinander an den Client. Wenn ein Client jedoch asynchrone Ereignisbenachrichtigungen nicht so schnell empfangen kann, wie die Ereignisse eingehen, beginnt WMI, Ereignisse automatisch in einem einzelnen Aufruf als Batch zu verarbeiten. Die automatische Batchverarbeitung hilft, wenn die Roundtripzeiten ein Problem darstellen, wie dies häufig in Szenarien mit hohem Durchsatz der Fall ist. Die Batchverarbeitung verbessert jedoch nicht die Systemleistung, wenn das Problem beim Client oder bei der Netzwerkbandbreite liegt.