Implémentation de l’interface principale pour un fournisseur de classes
Il existe deux façons d’implémenter un fournisseur de classes : implémenter l’interface en tant que fournisseur d’envoi (push) ou en tant que fournisseur d’extraction (pull).
Les sections suivantes seront abordées dans cette rubrique :
- Implémentation de l’interface principale pour un fournisseur de classes d’envoi (push)
- Implémentation de l’interface principale pour un fournisseur de classes d’extraction (pull)
Implémentation de l’interface principale pour un fournisseur de classes d’envoi (push)
Alors que tous les fournisseurs implémentent IWbemProviderInit pour l’initialisation et au moins une autre interface comme leur interface principale, un fournisseur d’envoi (push) implémente uniquement IWbemProviderInit.
Veillez à ce que votre implémentation effectue les tâches suivantes :
- Récupère les données de classe appropriées.
- Place les données dans le référentiel WMI.
- Supprime les données obsolètes.
Une fois le processus d’initialisation terminé, WMI gère toutes les demandes d’application pour les classes appartenant au fournisseur d’envoi (push) sans aucune autre interaction du fournisseur. Ensuite, le fournisseur d’envoi (push) agit en tant que client de WMI plutôt qu’en tant que fournisseur. Pour plus d’informations sur l’implémentation de IWbemProviderInit, consultez Initialisation d’un fournisseur.
Notes
Lorsque vous appelez WMI pour créer, mettre à jour ou supprimer des données dans un fournisseur d’envoi (push), définissez le paramètre lFlags de manière à inclure l’indicateur WBEM_FLAG_OWNER_UPDATE dans tous les appels aux méthodes IWbemServices.
Implémentation de l’interface principale pour un fournisseur de classes d’extraction (pull)
Un fournisseur de classes d’extraction (pull) doit implémenter IWbemServices en tant qu’interface principale. L’interface IWbemServices prend en charge la récupération, la mise à jour, la suppression et l’énumération des données, ainsi que le traitement des requêtes. Toutefois, comme IWbemServices est également utilisé par les applications et les fournisseurs pour demander des services de WMI, IWbemServices contient de nombreuses méthodes qui ne sont pas pertinentes pour un fournisseur de classes. Votre implémentation doit prendre en charge la récupération et l’énumération de classes, via les méthodes GetObjectAsync et CreateClassEnumAsync respectivement. Le tableau suivant répertorie les méthodes IWbemServices asynchrones supplémentaires que vous pouvez implémenter pour un fournisseur de classes.
| Méthode | Fonctionnalité |
|---|---|
| PutInstanceAsync | Modification |
| DeleteClassAsync | Suppression |
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 Appel d’une méthode.
Votre fournisseur de classes doit fournir une implémentation de stub qui retourne WBEM_E_PROVIDER_NOT_CAPABLE pour toutes les autres méthodes IWbemServices qui ne prennent pas en charge votre ensemble de fonctionnalités. Plus précisément, WMI ne prend pas en charge le traitement des requêtes pour les fournisseurs de classes. Par conséquent, un fournisseur de classes doit retourner WBEM_E_PROVIDER_NOT_CAPABLE à partir de son implémentation de IWbemServices::ExecQueryAsync, définir sa propriété d’inscription QuerySupportLevels sur NULL, ou les deux.
Les interfaces qu’un fournisseur de classes implémente sont très similaires à celles d’un fournisseur d’instances et d’un fournisseur de méthodes. En fait, un seul fournisseur peut agir comme les trois types de fournisseur en implémentant toutes les méthodes et en s’inscrivant correctement.